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The  apparent  lack  of  management  of  software  maintenance  within  D0D  and 
throughout  the  software  industry  has  given  rise  to  concern,  as  the  costs 
associated  with  software  maintenance  continue  to  increase.  The  major 
contributor  to  the  rise  in  maintenance  costs  seems  to  be  personnel  costs 
as  opposed  to  hardware  acquisition  or  computer  time.  However,  to-date, 
it  appears  that  little  research  has  been  conducted  to  attempt  to  resolve 
this  problem.  There  also  appears  to  be  a  lack  of  any  standard  definition 
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of  software  maintenance.  This  thesis  discusses  various  models  which  have 
been  developed  to  attempt  to  predict  maintenance  manloading  as  the  control¬ 
ling  factor  in  maintenance  costing.  It  evaluates  one  model  in  particular, 
and  proposes  a  possible  maintenance  versus  life  cycle  phase  relationship 
which  may  be  of  assistance  to  -the  software  manager  in  maintenance  man¬ 
loading  prediction.  It  also  proposes  specific  topics  for  further  research 
in  this  area. 
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ABSTRACT 


The  apparent  lack  of  aanageaent  of  software  aaintenance 
within  DOD  and  throughout  the  software  industry  has  given 
rise  to  concern,  as  the  costs  associated  with  software  aain- 
tenance  continue  to  increase.  The  aajor  contributor  to  the 
rise  in  aaintenance  costs  seeas  to  be  personnel  costs  as 
opposed  to  hardware  aquisition  or  coaputer  tiae.  However, 
to-date,  it  appears  that  little  research  has  been  conducted 
to  attempt  to  resolve  this  problea.  There  also  appears  to  be 
a  lack  of  any  standard  definition  of  software  aaintenance. 
This  thesis  discusses  various  aodels  which  have  been  devel¬ 
oped  to  atteapt  to  predict  aaintenance  aanloading  as  the 
controlling  factor  in  aaintenance  costing.  It  evaluates  one 
aodel  in  particular,  and  proposes  a  possible  aaintenance 
versus  life  cycle  phase  relationship  which  aay  be  of  assis¬ 
tance  to  the  software  aanager  in  maintenance  aanloading 
prediction.  It  also  proposes  specific  topics  for  further 
research  in  this  area 
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A .  BACKGEOOHD 

The  department  of  defense  for  the  last  twenty  to  thirty 
years  has  becose  sore  and  more  reliant  on  automatic  data 
processing  equipment  to  accomplish  its  seemingly  ever 
increasing  and  complex  mission.  When  this  trend  started, 
hardware  was  the  overriding  concern,  consuming,  in  1955, 
more  than  80  percent  of  the  data  processing  dollar  [  1  ]. 
Through  the  years,  technical  inovatiocs,  such  as  the  evolu¬ 
tion  from  vacuarn  tubes  to  discrete  transistors  and  from 
discrete  transistors  to  integrated  circuits,  coupled  with 
the  increased  use  of  mass  production  have  decreased  the  cost 
of  hardware.  However,  software  has  continued  to  rise  in 
price.  This  rise  in  the  price  of  software  and  the  decrease 
in  the  price  of  hardware  has  resulted  in  software  rapidly 
becoming  the  more  costly  of  the  two,  and  it  is  predicted 
that  by  1985  it  will  account  for  better  than  90  percent  of 
the  data  processing  dollar  [2]. 

The  true  impact  of  this  development  may  not  appear  to  be 
significant  until  one  realizes  that  the  value  of  this  soft¬ 
ware  in  1973  was  set  at  20  billion  dollars  for  the  United 
States  (3],  and  is  estimated  to  be  over  200  billion  dollars 
in  1985  [4]. 

As  a  direct  result  of  the  monetary  value  of  software 
production,  many  techniques  have  been  developed  to  estimate, 
at  the  start,  what  the  overall  life  cycle  cost  of  a  software 
project  will  be.  A  resent  study  conducted  by  Hughes 
Aircraft  Company  for  the  Air  Force  examined  twenty-one  of 
these  models  to  determine  commonalities  and  differences  in 
their  cost  estimating  approaches.  Ten  of  these  models  are 


limited  to  software  development  cost,  while  eleven  have 
software  support  cost  as  a  primary  or  secondary  output. 
Table  I  lists  all  of  the  models  studied,  in  alphabetical 
order .[  5  ] 

Originally,  it  was  thought  that  development  costs  were 
the  most  important  item  to  derive  and/or  estimate.  In  fact, 
the  development  and  design  efforts  for  a  new  system  are 
indeed  still  looked  upon  as  more  enjoyable  and  rewarding 
than  the  maintenance  effort  for  an  existing  system.  There 
are,  of  course,  many  reasons  for  this  view.  Six  of  these 
reasons,  according  to  Robert  Glass,  are  : 

1.  Haintenance  is  intellectually  very  difficult. 
Problems  cannot  be  bounded.  The  cause  could  be 
anywhere. 

2.  Haintenance  is  technically  very  difficult.  Problems 
cannot  be  specialized.  They  could  surface  because  of 
errors  in  the  coding,  design,  architecture,  or 
concept. 

3.  Haintenance  is  unfair.  Usually  the  person  who  is  main¬ 
taining  a  product  did  not  write  it  and  must  interpret 
what  the  original  author  meant.  Documentation  is 
inadequate  most  of  the  time. 

4.  Haintenance  is  no  -  win.  People  only  come  to  mainte¬ 
nance  with  problems. 

5.  Haintenance  is  infamous.  There  is  very  little  glory, 
noticeable  progress,  or  chance  for  ‘success*. 

6.  Haintenance  lives  in  the  past.  The  general  quality  of 
code  being  maintained  is  often  terrible.  This  is 
partly  because  it  wa3  created  when  everybody's  under¬ 
standing  of  software  was  more  rudimentary,  and  partly 
because  a  great  deal  of  code  is  produced  by  people 
before  they  become  really  good  at  programming.  [  6  ] 
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However,  more  and  aore  research  is  being  conducted  on 
the  aaintenance  aspect  of  software  cost  estiaation.  The 
reason  for  this  is  becoaing  apparent,  as  it  has  been  esti- 
aated  that  froa  forty  percent  to  ninety-five  percent  of  life 
cycle  costs  can  be  attributed  to  the  aaintenance  effort  [7]. 
The  reason  for  this  vide  range  of  estiaation  seeas  to  lie  in 
the  way  various  organizations  view  what  constitutes 
aaintenance. 

The  definition  of  software  aaintenance  appears  to  vary 
with  the  organization  and  seeas  to  be  effected  by  aanageaent 
constraints.  Software  maintenance  can  cover  the  spectrum 
froa  correction  of  bugs  caused  by  coding  errors  and  design 
inadequacies  to  enhancements  whose  purpose  is  to  add  whole 
new  ideas  and/or  design  concepts  not  specified  for  inclusion 
in  the  original  systea.  The  lack  of  a  standard  definition 
for  maintenance  is  a  aajor  contributor  to  the  paucity  of 
data  collection  in  this  area.  In  aany  organizations,  espe¬ 
cially  military,  as  top  level  management  personnel  rotate 
through  specific  positions,  different  definitions  of  what 
constitures  software  maintenance  also  rotate  through  those 
positions  and  the  organizational  levels  they  control,  is  a 
direct  result,  data  collection  requirements  change  to 
coapleaent  the  definition  of  aaintenance  and,  as  a  conse¬ 
quence,  no  consistent  track  of  a  project’s  manpower  usage 
history  can  be  recreated.  Of  greater  significance  is  the 
lack  of  a  standard  aaintenance  policy  within  the  organiza¬ 
tion  to  include  a  aaintenance  strategy  which  will  add  to  the 
degree  of  software  maintainability,  if  not  assure  it. 

In  view  of  the  large  costs  associated  with  software 
aaintenance,  GAO  conducted  a  study  which  reviewed  fifteen 
Federal  computer  installations  in  detail.  Their  findings 
pointed  to  two  aajor  contributors  to  the  problem ;  the  fact 
that,  in  the  majority  of  agencies,  aaintenance  is  not 


i 

managed  as  a  separate,  identifiable  function,  and  there  is 
|  an  absence  of  a  unifora  definition  of  aaintenance  [8]. 

GAO's  recoaaendations  included  development  of  a  standard 
definition  of  aaintenance  by  the  National  Bureau  of 
Standards  and  delineation  of  aaintenance  as  a  discrete  func- 
j  tion  by  agency  heads.  In  the  interia,  GAO  developed  a  check¬ 

list  of  iteas,  the  consideration  of  which  could  reduce 
aaintenance  costs.  In  the  checklist  is  a  set  of  categories 
for  recording  aaintenance  costs.  These  six  categories  appear 
j  to  reflect  GAO's  definition  of  aaintenance  and  as  such,  are 

listed  below: 

1.  Modify  or  enhance  software  to  sake  it  do  things  for 
the  end  user  that  that  were  not  requested  in  the  orig- 

|  inal  systea  design. 

2.  Modify  or  enhance  software  to  sake  it  do  things  for 
the  end  users  that  were  called  for  in  the  original 
design  but  which  were  not  present  in  the  first  produc¬ 
tion  version  of  the  software. 

3.  Beaove  defects  in  which  the  software  does  soaething 
other  than  what  the  user  wanted  ("does  the  wrong 
things") . 

4.  Reaove  defects  in  which  the  software  is  prograaaed 
incorrectly  ("does  the  desired  calculation,  but  gives 
an  incorrect  answer")  . 

5.  Optiaize  the  software  to  reduce  the  machine  costs  of 
running  it,  leaving  the  user  results  unchanged. 

6.  Make  miscellaneous  modifications,  such  as  those  needed 
to  interface  with  new  releases  of  operating 
systems. [  9] 

This  "definition"  appears  to  have  general  applicability  over 
the  broad  spectrum  of  activities  which  can  be  and  have  been 
grouped  under  the  category  of  software  maintenance.  However, 
number  one  may  cause  problems  in  the  context  of  aaintenance 
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cost  estimation  techniques  based  on  the  Rayleigh  curve. 
Since  enhancements  necessarily  require  some  design/develop¬ 
ment  effort  by  their  very  nature  (they  give  the  product 
capabilities  not  called  for  in  the  original  design) ,  the 
manning  level  in  such  effort  vould  exhibit  a  rise  and  then  a 
fall  in  magnitude  in  the  Rayleigh  fashion,  thus  creating  a 
series  of  small  Rayleigh  curves  within  the  maintenance 
phase.  As  long  as  this  behavior  did  not  vary  greatly  from 
the  normal  maintenance  effort  for  that  project,  it  would  not 
have  much  effect  on  the  project.  However,  if  the  front  end 
of  the  curve  rose  beyond  some  predefined  maintenance  support 
boundary,  then  it  would  indicate  the  presence  of  a  full 
scale  development  project  instead  of  a  pure  maintenance 
effort,  and  it  should  signal  the  completion  of  the  old 
project  and  the  start  of  a  new  one.  Therefore,  because  of 
the  nature  of  the  software  life  cycle,  even  a  standard  defi¬ 
nition  of  maintennace  has  grey  areas  and  management  judge¬ 
ment  must  be  used  in  its  application. 

The  GAO  definition  does,  as  stated  earlier,  provide  a 
good,  general  definition  of  software  maintenance  and,  as 
such,  for  the  purposes  of  this  thesis,  software  maintenance 
encompasses  all  of  its  categories. 

B.  PHOBLEH  DEFINITION 

James  F.  Green  and  Brenda  F.  Selby,  formerly  of  the 
Naval  Postgraduate  School,  having  reviewed  Putnam's  Software 
Cost  Estimating  Hodel,  the  Army  Hacro-estimating  Hodel,  the 
Lehman- Bel ady  Hodel,  and  the  Parr  Hodel,  have  proposed  a 
dual  theory  for  maintenance  requirements  estimation.  They 
proposed  that,  if  one  considered  maintenance  to  include  all 
effort  applied  to  a  software  project  from  the  time  that  the 
product  was  released  to  the  user,  that  the  peak  maintenance 
manloading  required  could  be  calculated  by  computing  the 


inflection  point  on  a  Rayleigh  carve  for  the  total  software 
life  cycle  effort.  They  further  predicted  that  one  could 
predict  the  einieue  saints  nance  aanloading  requiraents  by 
computing  the  inflection  point  on  the  Bayleigh  curve  repre¬ 
senting  the  naintenance  life  cycle. 

The  proposed  Green/Selby  Model,  upon  cursory  examina¬ 
tion,  appears  to  have  tresendous  potential  as  a  tool  for  the 
aanager  of  software  projects.  However,  Green  and  Selby  were 
not  able  to  obtain  sufficient  data  to  thoroughly  validate 
the  applicability  of  the  model  to  real  world  situations. 
Therefore,  such  further  work  is  needed  in  this  area. 

C.  RESEARCH  OBJECTIVES 

The  objectives  of  the  research  are  twofold:  to  evaluate 
the  Green/Selby  sodel  for  prediction  of  maintenance  costs 
via  projection  of  maintenance  aanloading,  both  for  mainte¬ 
nance  team  development  and  for  out  year  support  resource 
estimation,  and  to  provide  an  analysis  of  applications  of 
the  aodel  in  areas  other  than  project  management  and 
control.  The  Green/Selby  model  addresses  two  areas,  a  main¬ 
tenance  planning  concept  which  is  concerned  with  the  overall 
maintenance  strategy  as  applied  to  a  particular  software 
project  and  a  maintenance  control  concept  which  is  concerned 
with  aanloading  requirements  estimation.  Only  the  latter 
will  be  dealt  with  in  this  research. 

The  evaluation  of  the  aodel  will  be  accomplished  in  the 
pursuit  of  three  subobjectives.  The  first  is  to  provide  an 
analysis  of  software  maintenance  costing  problems  and  a 
synopsis  from  the  literature  of  other  existing  models  and 
techniques,  some  of  which  were  used  in  the  initial 
Green/Selby  aodel  development,  and  some  of  which  the  authors 
feel  are  of  equal  importance  and  which  may  contribute  to 
further  development  or  application  of  the  Green/Selby  aodel. 


The  second  subobjective  is  to  validate  the  development  of 
the  Green/Selby  aodel  through  analysis  of  the  mathematical 
relationships  and  through  recreation  of  the  enpirical  devel¬ 
opment.  The  third  subobjective  is  to  validate  the  model  with 
actual  data  from  as  many  different  sized  software  projects 
as  possible  to  ascertain  the  degree  to  which  the  aodel  is 
applicable  to  real  world  software  costing  problems. 

Based  on  the  results  of  the  data  analysis,  projections 
will  be  made  as  to  possible  applications  of  the  model  in 
areas  other  than  cost  estimation,  if  such  applications 
appear  to  exist. 

0.  ASSOHPTIONS/LIHIT &TI0NS 

Three  major  assumptions  were  made  at  the  onset  of  the 
research  effort  for  this  thesis.  Other  assumptions  were 
necessary  at  specific  junctures  of  the  research  but  they  do 
not  apply  in  every  case,  so  they  are  discussed  where  they 
are  applicable.  The  major  assumptions  are  as  follows: 

1.  It  was  assumed,  based  on  limited  prior  study  in  the 
subject  area,  that  the  software  project  life  cycle  and 
all  of  its  phases  followed  the  general  pattern  of  the 
Rayleigh  curve. 

2.  It  was  assumed  that  the  Sreen/Selby  Model  was  valid  in 
its  development  though  not  thoroughly  tested  in  its 
application. 

3.  It  was  assumed  that  there  is  little  difference  in  how 
project  size  affects  the  manning  behavior  of  a  project 
during  the  individual  phase  cycles  and  during  the 
total  project  life  cycle. 

Three  major  constraints  were  found  to  limit  the  research 
effort.  They  are  as  follows: 

1.  There  was  found  to  be  a  serious  lack  of  readily  avail¬ 
able  data  which  applied  to  the  maintenance  phase. 


2.  There  appears  to  have  been  little  aajor  research  done 
in  the  area  of  software  maintenance  unload ing/cost 
estimation. 

3.  Because  of  the  nature  of  the  subject  area  and  the 
variance  of  eaintenance  data  collection  across  organi¬ 
zations,  the  research  conpleted  and  data  collected  to 
date  appears  to  have  involved  what  are  recently  being 
categorized  as  inefficient  and  maintenance-intensive 
design  techniques.  Therefore,  the  applicability  of 
early  works  and  present  research  using  old  data  say 
become  suspect,  if  not  invalid,  by  the  use  of  such 
techniques  as  modularization,  information  hiding 
modules,  and  the  use  of  other,  recently  developed, 
software  tools.  Hence,  the  new  methods  may  alter  the 
old  relationships  entirely. 

E.  RESE&RCH  METHODOLOGY 

The  research  methodology  implemented  by  the  authors  of 
this  thesis  was  fivefold,  to  include  literature  search,  data 
search/collection,  research  design,  model  validation,  and 
data  analysis /evaluation. 

&  literature  search  was  conducted  both  by  manual  and 
automated  means.  &  manual  search  produced  most  of  the  refer¬ 
ences,  used  by  Green  and  Selby,  which  were  used  to  provide 
the  researchers  with  a  solid  background  in  the  area  of  study 
and  to  recreate,  as  closely  as  possible,  the  knowledge  base 
from  which  the  Green/Selby  model  was  developed.  Two  auto¬ 
mated  searches  were  conducted,  one  through  the  Defense 
Logistics  Information  Studies  Exchange  (DLSIE)  and  one  via 
the  computerized  library  search  network.  Both  searches 
produced  numerous  writings  of  interest  from  the  private  and 
military  sectors. 


The  search  for  data  highlighted  the  largest  single  stum- 
bling  block  to  research  in  the  area  of  software  aaintenance, 
that  of  a  lack  of  adequate  data  collection  by  maintaining 
activities.  Actual  aanloading  records  have  usually  been 
kept  during  the  developaent  phases  of  nuaerous  software 
projects;  however,  aaintenance  data  appears  to  have  been 
recorded  only  recently,  and  then  only  sporadically  at  best. 
The  search  for  data  was  conducted  successfully  via  telephone 
conversations  with  the  following  persons/organizations; 
Goddard  Space  Flight  Center,  Greenbelt,  Md. ;  and 
Dr.  Rilla  Kay  Weiner- Ehr lich,  consultant.  Bankers  Trust 
Co.  ,  NY,  NY. 

The  following  organizations  were  contacted  in  the  course  of 
the  search  with  no  significant  results: 

Data  And  Analysis  Center  for  Software,  Griffis  AFB,  NY; 
United  States  Army  Computer  Systems  Command,  Ft.  Belvoir, 
Va.  ; 

Aeronautical  Systems  Division,  Wright  Patterson  AFB, 
Dayton,  Ohio;  and 

Data  Systems  Design  Center,  Gunter  AFSTA,  Montgomery,  Ala. 
Valuable  support  and/or  referral  information  were  received 
from  the  following  persons: 

Dr.  Robert  Grafton,  Office  of  Naval  Research,  Washington, 
D.C.; 

Dr.  Victor  Bascili,  University  of  Maryland,  College  Park, 
Hd.  ; 

Hr.  David  Weiss,  Naval  Research  Laboratory,  Washington, 
D.  C. ; 

Ms.  Cheryl  Maloney  and  Mr.  Robert  Jones,  United  States 
Army  Computer  Systems  Command,  Ft.  Belvoir,  Va.  ;  and 
Mr.  Lawrence  Putnam,  auantitative  Software  Management, 
Inc.,  McLean.  Va. 


The  NASA  SEL  data  base,  which  contains  data  on  about 
forty  software  projects,  was  received  from  the  Data  and 
Analysis  center  for  software,  but  it  was  discovered  that 
aaintenance  data  is  just  now  being  collected,  and  no  signify 
leant  aggregate  will  be  available  for  approxiaately  two 
years. 

A  report,  produced  for  the  Air  Force  by  General  Research 
Corporation  of  Santa  Barbara,  Ca. ,  indicated  that  the 
Planning  and  Resource  flanageaent  Infornation  System  (PARRIS) 
at  the  Air  Force  Data  Systeas  Design  Center  (AFDSDC) ,  Gunter 
AFSTA ,  Hontgomery,  Ala.,  held  a  large,  relatively  untapped, 
data  base  of  aanpower  usage  (projected  and  actual)  froa 
about  2000  projects.  However,  the  data  search  revealed  that 
PAR HIS  was  replaced  by  a  new  Personnel  Cost/  Accounting 
Systea  in  1977/1978  and  it  appears  that  the  former  data  base 
was  deleted  due  to  foraat  incompatibilities  with  the  new 
systea. 

As  such,  it  is  apparent  that  little  maintenance  data  is 
available  or,  if  in  existence,  it  is  very  difficult  to 
locate. 

Once  a  knowledge  base  was  developed  and  data  collected, 
the  research  process  was  begun.  That  process  is  listed  in 
general: 

A.  Develop  mathematical  relationships  in  terms  of  equa¬ 
tions; 

B.  Validate  Green/Selby  model  development; 

C.  Analyze  empirical  project  data  in  terms  of  Green/Selby 
model;  and 

D.  Interpret  data  analysis. 

In  order  to  attempt  to  validate  the  Green/Selby  model, 
the  model  development  was  recreated  as  closely  as  possible 
using  the  same  or  similar  data. 


Data  analysis  was  conducted  by  using  various  non-linear 
curve  fitting  techniques  to  fit  actual  life  cycle  aan- 
loading  values  to  the  Bayleigh  aodel.  Then,  Green/Selby 
■odel  relationships  were  calculated  and  plotted  against 
■aintenance  phase  values.  The  above  techniques  allowed  eval¬ 
uation  of  applicability  of  the  Green/Selby  aodel  with  actual 
project  data. 


P.  OVERVIEW  OP  THE  THESIS 

In  this  introductory  chapter,  the  tera  software  'mainte¬ 
nance1  was  defined  and  its  importance  in  the  context  of  the 
data  systeas  organization  was  discussed.  The  problea  to  be 
considered  in  this  thesis  has  been  presented  and  the  objec¬ 
tives  of  the  research  effort  intended  to  resolve  the  problea 
have  been  delineated.  Assuaptions  aade  at  the  onset  of  the 
research  effort  and  aajor  limitations  encountered  during  the 
course  of  the  research  were  discussed.  Pinally,  the  research 
aethodology  was  outlined.  Chapter  II  looks  at  various 
aodels  and  cost  estimating  techniques  which  were  used  as  a 
basis  for  the  development  of  the  Green/Selby  model.  It  also 
includes  a  synopsis  of  other  models  which  the  researchers 
feel  are  c*  importance  to  the  particular  area  of  study. 
Chapter  III  presents  an  in-depth  analysis  of  the  Green/Selby 
aodel,  and  its  proposed  applications.  Chapter  IV  provides  a 
aatheaatical  and  empirical  validation  of  the  model,  using 
siailar  data  to  that  used  by  Green  and  Selby  originally. 
Chapter  V  discusses  the  data  analysis,  and  thus,  the  empir¬ 
ical  model  validation  evaluation.  Finally,  Chapter  VI  summa¬ 
rizes  the  thesis  and  presents  conclusions  and 
recoaaendations. 


XI.  SOmiBS  SAimfilfifiS  £0§x  U21M21Q* 


A.  CUHBEHT  TECHNIQUES  USED  AS  A  BASIS  FOB  THE  SBEEN/SELBY 
HOD  EL 

1,  Putnam' s  Soft  ware  Cost  Estimating  Model 

Patnaa  developed  his  method  for  software  cost  esti- 
aation  by  studing  various  systems  designed  by  the  United 
States  Army  Computer  Systems  Command  (USACSC)  and  comparing 
them  to  the  Hayleigh  life  cycle  profile  developed  by  Peter 
?•  Borden  in  the  1960 *s.  This  life  cycle  profile,  depicted 
in  Figure  (2.1),  linked  the  individual  cycles  of  each  of  the 
life  cycle  phases  and  added  them  together  producing  the 
profile  for  the  entire  project.  Putnam's  empirical  studies 
showed  that,  for  the  system  studied,  the  software  life  cycle 


Figure  2. 1  Hayleigh  Project  Life  Cycle  Profile 
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exhibits  a  rise  in  aanpover  up  to  a  peak  and  then  a  trailing 
off  portion  corresponding  very  well  with  Norden's  Rayleigh 
curve. 

Putnae  attempts  to  answer  the  questions  "Row  do  I 
know  how  long  a  software  project  will  take,  and  how  auch 
will  it  cost'*?  [10]  In  order  to  do  this,  Putnaa  analyzes 
the  following  areas: 

•  Optiaua  Man-loading  over  life  cycle 

•  Total  Manpower  over  life  cycle 

•  Cost  per  year 

•  Life  Cycle  cost  in 

•Current  $ 

•Inflated  $ 

•Discounted  $  (for  3. i.) 

•miniaua  $  benefits  to  break  even  over  economic  life 

•  Risk  profiles  for: 

•Manpower 

•Costs 

•Project  coapletion  [11] 

The  Rayleigh  aodel  for  cuaulative  manpower  utiliza¬ 
tion,  used  by  Putnaa,  is  given  by  the  formula 

2 

-at 

Y  »  K ( 1-e)  ,  (2.1) 

where 

Y  *  cuaulative  aanpover  used, 

K  *  the  total  number  of  man-years  of  life  cycle 

effort, 

a  *  the  curve  shape  paraaeter,  and 

t  a  the  elapsed  tiae  in  years. 

However,  the  aost  popular  fora  of  the  curve  is  the  deriva¬ 
tive  fora  for  current  manpower  utilization  expressed  by 

2 

-at 

Y*  *  2 Kate  .  (2.2) 

Empirically  derived: 
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(2-3) 


a  *  1/2t  , 

a 


where 

t  *  the  tine  to  reach  peak  effort, 
d 


In  terns  of  software  projects,  t  has  been  empirically  shown 

a 

to  correspond  very  closely  to  the  aesign  tine  (or  the  tine 


to  reach  initial  operational  capability)  of  a  large  software 
project  (12]. 


with  t  representing  the  development  tine  for  the 
d 

system,  equation  (2.3)  can  be  substituted  into  the  Rayleigh 


equation,  and  the  shape  of  the  curve,  together  with  the 
acconpanying  equation,  allow  us  to  project  what  the  manpower 
requirements  and  cash  flow  for  systen  development  will  be  at 
any  given  time.  (Cash  flow  is  calculated  by  multiplying 
manpower  projections  by  the  current  personnel  salaries.) 
The  equation  representing  this  curve  is[13] 


Y« 


2  2 
2  -(t  /2t  ) 

KA  te.  d 

a 


(2.4) 


Putnam  found  that  there  was  a  fundamental  relation¬ 
ship  in  software  development  between  the  number  of  source 
statements  in  the  system  and  the  effort,  development  time, 
and  the  state  of  technology  being  applied  to  the  project. 
The  equation  that  describes  this  relationship  is  : 


1/3  4/3 

Ss  *  Ck  K  t 


(2.5) 


where 

Ss  *  the  number  of  end  product  source  lines  of  code 
delivered, 

K  *  the  life  cycle  effort  in  man-years, 
t  *  development  time,  and 

Ck  »  a  state  of  the  technology  constant. 


At  least  three  different  estimates  of  prograa  size 
shoald  be  aade  before  development  of  the  systea  begins. 
They  shoald  be  aade  once  daring  the  systea  definition  phase 
and  at  least  twice  daring  the  functional  design  and  specifi¬ 
cation  phase.  This  will  insure  a  very  realistic  estiaate  of 
the  size  of  the  systea.  Admittedly,  estimation  of  Ss  and  Ck 
are  ertreaely  difficult;  however,  if  siailar  projects  have 
been  done  in  the  past  their  values  shoald  reaain  fairly 
constant. [  14] 

Putnam's  model  see  as  to  work  extremely  well  with 
large  scale  software  projects  but  it  does  not  seea  to  fit 
well  for  projects  under  10  ,000  lines  of  source  code  [15]. 
The  largest  problem  with  the  use  of  Putnam's  model  is  the 
reliance  on  past  experience  and  historical  data  banks,  if  in 
fact  they  exist,  to  estimate  the  size  and  complexity  of  the 
current  project.  It  also  pays  little  attention  to  operation 
and  maintenance  costs  after  development  is  complete  or  non¬ 
aan  power  related  iteas  such  as  conputer  time  and  travel 
allowances  which  may  influence  total  life  cycle  costs  to  a 
great  extent. 

2.  Payr* s  Software  £2§t  Estimating  Model 

The  Parr  model  was  developed  by  P.  H.  Parr  after  he 
had  studied  the  work  done  by  Norden  and  Putnam  on  the 
Rayleigh  curve.  Parr  was  concerned  that  the  Rayleigh  curve 
failed  to  answer  questions  about  the  learning  curves  usually 
associated  with  the  start  of  new  projects.  He  also  felt 
that  it  made  the  assumption  that  the  skill  available  for  a 
project  depends  on  resources  which  have  been  applied  to  it. 
This,  he  states,  confuses  the  intrinsic  constraints  of  the 
linear  learning  curve  with  the  rate  at  which  software  can  be 
written,  based  on  management's  economically  governed  choices 
in  response  to  these  constraints.  Parr  further  states  that; 


The  process  generally  used  to  develop  new  software  can 
be  thought  of  as  the  successive  solution  of  a  large  number 
of  small  problems.  The  solution  of  each  of  these  indi¬ 
vidual  problems  is  a  decision  which  defines  some  feature 
of  the  final  program.  A  development  project  corresponds 
to  starting  out  with  some  fixed  bounded  set  of  problems  to 
be  solved  and  ending  with  enough  decisions  having  been 
made  for  a  working  product  to  be  available. [  16  ] 

Parr  utilized  a  binary  tree  concept  to  statistically 
determine  the  number  of  possible  problems  and  decided  that 
the  proportion  of  the  problems  solved  at  time  t,  denoted  as 
H(t),  was  given  by  the  formula 


-at 

B(t)  *  1/(1  ♦  A  e  ), 


(2.6) 


where 


A  *  a  constant,  and 
a  3  shape  parameter. 

By  solving  this  equation,  he  could  determine  the 
expected  change  in  the  size  of  the  visible  unsolved  node  set 
as  a  linear  function  of  the  work  completed.  The  importance 
of  this  was  that  he  determined  that  the  rate  at  which  work 
could  be  usefully  input  to  the  development  process  was 
proportional  to  the  size  of  the  set  of  visible  unsolved 
problems,  V  (t) .  He  further  determined  that  when  the  optimal 
input  effort  is  applied,  steps  in  the  development  would  be 
achieved  at  a  rate  proportional  to  V(t).  Thus  the  work-rate 
could  be  determined  by  solving  for  7 (t)  which  he  developed 
into  the  equation  : 


V(t)  =  (1/4)  sech  ((at  ♦  c3)/2). 


(2.7) 


where 


c3  *  an  integration  constant. 

Figure  (2.2)  shows  the  resulting  curve  overlayed  on  a  corre¬ 
sponding  Rayleigh  curve. 

It  can  be  seen  that  the  back  portion  of  the  sech- 
squared  function  correlates  very  highly  with  the  Ravleigh 


Figure  2.2  Comparison  of  Sech*  and  Rayleigh  Carves 


carve.  However,  the  front 
fined  starting  point,  as 
curve.  Parr  feels  that 
represents  that  portion  of 
starting  date  for  a  proje 
realistic  than  the  Rayleigh 
Parr  went  on  to 
introduced  by  the  increased 
and  developed  the  formula: 


portion  does  not  show  a  well-de- 
is  the  case  with  the  Rayleigh 
the  front  portion  of  the  curve 
the  work  done  before  the  official 
ct.  He  feels  that  this  is  more 
curve. 

explore  the  complexity  factors 
usage  of  structured  programming 


7(t) 


-2 

[aAe 


at  -2at 

/  (1  ♦  Ae  )  ]/a. 


(2.8) 


The  resulting  curve  has  its  peak  shifted  slightly  to 
the  right  of  the  sech-sguared  function;  which  predicts  that 
peak  work  rate  will  occur  after  half  the  project  has  been 
done.  This  he  asserts  is  in  keeping  with  the  theory  that 
design  may  be  slower,  but  there  will  be  a  compensating 
reduction  in  testing  and  maintenance  effort. 


Having  already  developed  a  number  of  software 
systems,  the  iray  decided  that  it  needed  a  aethod  which 
would  be  simple,  effective,  and  reasonably  accurate  for 
deteraining  and  controlling  aanpower  and  dollar  resources 
for  any  point  in  the  software  life  cycle. 

After  reviewing  the  data  on  its  existing  systeas, 
the  Amy  chose  the  aatheaatical  relationship  developed  by 
Nor den  where: 

2 

-at 

Y*  »  2 Kate.  (2.9) 

This  equation  was  the  saae  one  used  by  Putnan,  and  it  was 
used  by  the  Aray  to  derive  the  various  nilestonas  to  be  used 
by  systea  managers.  By  comparing  the  actual  resources  used 
when  these  ailestones  were  reached#  the  action  officer  could 
take  corrective  action  if,  statistically,  those  resources 
used  were  outside  the  control  Units. 

These  ailestones  were  developed  based  on  step-by- 
step  procedures  given  in  the  following  cases: 

£323  I:  £12*31  ilssiil  3£i3I  (resources 

Using  budget  data,  the  aaxiaua  level  of  manpower 

(I*  )  and  the  number  of  years  to  reach  maxinun  effort 

aax 

(t  )  is  determined,  aather  than  compute  the  values  for 

Y  'max 

out  year  aanpower  loading.  Table  II  is  used  to  compute  the 
values  of  Y*  for  the  appropriate  t  -By  multiplying  any 
entry  opposite  its  time  period  by  K,  the  appropriate  number 
of  nanyears  are  obtained.  The  units  of  K  and  t  will  deter- 
nine  the  diaensions. 
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Total  aan-years  of  effort  and  peaK  time  for  manpower 
loading  is  derived  using  Bayes*  theorem.  Based  on  eapirical 
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probability  of  occurence  of  each  type.  Using  estimates 
based  on  past  US&CSC  experiences  (the  average  K  value  for 
all  systeas  under  development  and  average  K  for  the  func¬ 
tional  type  of  system),  initial  estimates  for  a  new  develop¬ 
ment  are  calculated  from  regression  graphs.  Then,  applying 
Bayes*  theorem  to  average  these  individual  estimates  in  the 
weighted  probability  sense  yields  a  better  estimate  of  K 
with  a  smaller  standard  deviation  (i.  e.  better  confidence  in 
the  estimate).  To  improve  estimates  and  reduce  uncertainty, 
Bayes*  theorem  is  successively  applied. [17] 

4.  The  Lehman- Be  lady  Model 

L.  1.  Belady  and  M.  R.  Lehman  developed  their  model 
by  studing  the  management  and  evolution  of  the  OS/360  oper¬ 
ating  system.  They  felt  that  this  system  gave  them  a  good 
view  of  the  processes  and  managerial  thinking  that  goes  into 
the  development  and  programming  of  medium  to  large-sized 
projects.  The  decision  to  use  this  system  was  reached  after 
they  had  surveyed  a  number  of  versions  and  releases  of 
OS/ 36 0  before  their  study  began.  The  data  for  each  release 
included  measures  of  the  size  of  the  system,  the  number  of 
modules  added,  or  changed,  the  release  date,  information  on 
manpower  used,  machine  time  used  and  costs  involved  in  each 
release.  In  general,  there  were  large,  apparently 
stochastic,  variations  in  the  individual  data  items  from 
release  to  release. 

The  data  exhibited  a  general  upward  trend  in  the 
size,  complexity,  and  cost  of  the  system  and  the  maintenance 
process.  This  was  indicated  by  comparing  the  components, 
statements,  instructions,  and  modules  handled  over  the 
system  life  cycle.  The  various  parameters  were  averaged  to 
expose  trends.  When  averaged,  previously  erratic  data 
appeared  to  become  strikingly  smooth,  displaying  nonlinear  - 
possibly  exponential  -  growth  and  complexity. 
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As  a  result  of  their  research,  they  postulated  three 


laws  of  Program  Evolution  Dynamics. 

I.  Law  of  continuing  change 


I.  Law  of  continuing  changg,  A  system  that  is  used 
undergoes  continuing  change  until  it  is  judged  more  cost 
effective  to  freeze  and  recreate  it. 


rogram 
hat  it 
viron- 


complexity  and  reduc- 
by  the  Second  Law  of 

The  entropy  of  a 
es  with  time,  unless 


Software  does  not  face  the  physical  decay  problems 
that  hardware  faces.  But  the  power  and  logical  flexi¬ 
bility  of  computing  systems,  the  extending  technology  of 
computer  applications,  the  ever-evolving  hardware,  and  the 
pressures  for  the  exploitation  of  new  Business  opportuni¬ 
ties  all  make  demands.  Manufacturers,  therefore, 
encourage  the  continuous  adaptation  of  programs  to  keep  in 
step  with  increasing  skill,  insight,  ambition,  and  oppor¬ 
tunity.  In  addition  to  such  external  pressures  for 
change,  there  is  the  constant  need  to  repair  system 
faults,  whether  they  are  errors  that  stem  from  faulty 
implementation  or  defects  that  relate  to  weaknesses  in 
design  or  behavior.  Thus,  a  programming  system  undergoes 
continuous  maintenance  and  development,  driven  by  mutually 
stimulating  changes  in  system  capability  and  environmental 
usage.  In  fact,  the  evolution  pattern  of  a  large  program 
is  similar  to  that  of  any  other  complex  system  in  that  it 
stems  from  the  closed-loop  cyclic  adaptation  of  environ¬ 
ment  to  system  changes  and  vice  versa. 

As  a  system  is  changed,  its  structure  inevitably 
degenerates.  The  resulting  system  complexity  and  reduc¬ 
tion  of  managerability  are  expressed  by  the  Second  Law  of 
Program  Evolution  Dynamics. 

II.  Law  of  increasing  entropy.  The  entropy  of  a 
system  (its  unstructuredness)  increases  with  time,  unless 
specific  work  is  executed  to  maintain  or  reduce  it. 

This  law  too  expresses  vast  experience,  in  part  by 
data... This,  in  turn,  leads  to  the  formulation  of  the 
Third  Law  or  Program  Evolution  Dynamics. 

III.  Law  of  statistically  smooth  growth.  Growth 
trend  measures  of  global  system  attributes  may  appear  to 
be  stochastic  locally  in  time  and  space,  but,  statisti¬ 
cally,  they  are  cyclically  self-regulating,  with  well-de¬ 
fined  long-range  trends. 

The  system  and  the  metasystem  -the  project  organiza¬ 
tion  that  is  developing  it-  constitute  an  organism  that  is 
constrained  by  conservation  laws.  These  laws  may  be 
locally  violated,  but  they  direct,  constrain,  control,  and 
thereby  regulate  and  smooth,  the  long-term  growth  and 
development  patterns  and  rates.  Observation,  measurement, 
and  interpretation  of  the  latter  can  thus  be  used  to  plan, 
control,  and  forecast  better  the  product  of  an  existing 
process  and  to  improve  the  process  so  as  to  obtain  desired 
or  desirable  characterist ics. [  18] 

Having  postulated  these  three  laws,  they  commenced 
the  process  of  defining  a  complexity  factor  C (R)  for  the 
various  program  releases,  each  of  which  were  assigned 
Release  Sequence  Numbers  (BSN's)  .  Prom  the  available  data 
they  proposed  the  formula: 


where 

H  (B)  measures  the  size  of  the  the  systea  in 
aodules  and 

H  (HR)  records  the  nuaber  of  systea  aodules 
that  have  received  attention. 

Utilizing  this  complexity  factor,  they  stated  that 
the  design  -  programming  -  distribution  usage  systea  has  a 
feedback  driven  and  controlled  transfer  function  and  an 
input-output  relationship.  This  feedback  results,  some¬ 
times,  froa  constant  pressure  to  supplement  systea  capa¬ 
bility  and  power.  This  constant  pressure  normally  results 
in  work  pressures  building  up  as  growth  rate  increases. 
Accordingly,  the  growth  rate  increases  the  size  and 
complexity  of  the  systea  and  reduces  the  quality  of  design, 
coding,  and  testing.  This  is  accompanied  by  lagging  docu¬ 
mentation,  and  other  factors,  which  eaerge  to  counter  the 
increasing  growth  rate. 

Eventually,  the  above  relationship  resulted  in  the 
need  for  a  system  consolidation  in  which  correction, 
restructuring,  and  rewriting  were  done  with  few,  if  any, 
functional  enhancements.  The  consolidation  often  results  in 
the  shrinking  of  a  systea  during  such  a  release,  rather  than 
the  growing  normally  experienced  with  each  new  release. 
This,  they  observed,  occurred  with  every  twenty  to  twenty- 
one  releases  of  the  systea.  They  further  observed  that 
successful  releases  appeared  to  have  an  upper  bound  of  about 
400  aodules. 

Since  the  majority  of  managers  base  their  decisions 
on  available  budgets,  Lehman  and  Belady  proposed  that  the 
total  expenditure  for  all  activities  involved  wirh  the 
project  be  equal  to  the  budget,  and  hence,  the  formula  for 
the  budget  (B)  is  given  by: 

B  «  P  ♦  A  ♦  C  (2.11) 
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where 


P  is  units  of  fault  extraction  activity 
termed  progressive, 

1  is  the  amount  of  resources  associated  with 
documentation,  administration,  communication, 
and  learning  activity  termed  an tiregressive. 

C  is  the  increasing  work  demanded  to  cope  with 
the  neglect  of  A,  and  is  given  by  the  formula 
.*t 

C  ■  r  (1-m)  kPdt,  and  (2.12) 

where 

m  and  k  are  defined  below. 

The  formula  for  antiregressive  activities  is: 

4  *  mkP  (2. 13) 

where 

a  is  the  management  factor,  which  is  the 

fraction  of  progress,  kP,  that  is  actually 

dedicated  by  management  to  A  activity,  and 

k  represents  the  inherent  A  activity  required 

for  each  unit  of  P  activity  so  that  complexity 

does  not  grow  and  is  given  by  the  formula 

k  *  A  /  P.  (2.14) 

Hanagement  is  assumed  to  have  full  control  of  the 
allocation  of  its  resources  and  the  division  of  effort 
between  P-.  and  A- type  activities.  Hanagement  cannot, 
however,  directly  control  the  growth  in  complexity  that 
accumulates,  except  by  utter  concentration  on  complexity 
control  through  restructuring.  This  is  an  activity  that  is 
strictly  antiregressive  and,  as  such,  is  psychologically 
difficult  to  inspire,  since  it  yields  no  direct,  short¬ 
term,  benefits.  [19] 

An  interpretation  of  their  model  suggests  that  more 
rapid  work  leads  to  greater  pressures  on  the  team,  and  hence 
more  errors.  This,  in  turn,  requires  greater  repair 
activity.  However,  the  data  indicates  that  this  problem  is 
mainly  incurred  in  the  same  release  rather  than  discovered 
and  undertaken  thereafter.  Futhermore,  since  it  appears  to 


lead  to  an  increase  in  the  fraction  of  the  system  handled, 
it  suggests  that  the  maintenance  teams  tend  to  remove  the 
symptoms  of  a  fault  rather  than  to  locate  and  repair  its 
cause.  This  problem  is  reduced  through  proper  communica¬ 
tion,  documentation,  and  learning  by  the  programming 
team. [20  ] 

B.  OTHEB  MODELS  OP  INTEREST 
1 .  Jensen  Model 

Randall  W.  Jensen  [21]  stated  that,  because  tradi¬ 
tional  intuitive  estimation  methods  consistently  produce 
optimistic  results  which  contribute  to  the  too  familiar  cost 
overrun  and  schedule  slippage,  customers  for  software  prod¬ 
ucts  are  becoming  less  willing  to  tolerate  the  losses  asso¬ 
ciated  with  inaccurate  estimates.  He,  therefore,  derived 
his  model  based  primarily  on  the  work  done  by  Norden, 
Putnam,  and  Doty  Associates. 

In  conjunction  with  the  familiar  Rayleigh  equation 


-at 

r*  »  2 Kate, 


(2.  15) 


Jen sen* s  model  consists  of  a  series  of  equations  for  system 
productivity,  initial  project  staffing  rate,  system 
complexity,  system  size,  development  effort,  and  risk 
analysis. 

He  defines  the  productivity  relationship  by  the 
equation: 


where 


PR  *  C  (K/t  )  , 
a  d 


average  project  productivity  (source 
lines  per  year). 

Total  life  cycle  cost  in  manyears. 


(2.16) 


t  »  developaent  tiae  in  years  and  is  defined 
d 

as  the  peak  tine  for  the  Rayleigh  curve, 

C  *  a  proportionality  constant,  and 
n 

B  »  slope  of  productivity  relationship. 

While  this  equation  is  not  actually  related  to  the 
systea  difficulty,  it  is  related  to  the  rate  at  which  staff 
is  applied  to  the  task.  Intuitively,  productivity  is  an 
inverse  function  of  the  nuaber  of  people  directly  involved 
with  a  developaent  task  due  to  the  associated  losses  caused 
by  the  nuaber  of  ccaaunica tion  paths  in  the  organization. 
This  phenoaenoa  can  be  accounted  for  by  utilizing  the 
relationship 

2 

H  »  K/t  ,  (2.  17) 

d 

which  is  the  formula  for  the  initial  project  staffing  rate, 
H,  and  is  ertreaely  important  in  determining  the  optimum 
project  staffing  rate. 

Host,  if  not  all,  of  the  projects  studied  by  Jensen, 
appeared  to  demonstrate  a  consistent  pattern  which  could  be 
used  to  classify  each  project  into  distinct  categories. 
These  categories  were  dependent  on  the  interface  complexity, 
logical  complexity,  and  the  percentage  of  new  developaent  in 
the  system,  all  of  which  seemed  to  be  defined  by  the  ratio 

3 

K/t  .  (2.18) 

<z 

The  expression  K/t3,  in  a  practical  sense,  represents 

d 

a  natural  equilibrium  between  the  lifecycle  cost  and  devel¬ 
opaent  tiae  for  a  specific  class  of  software  projects.  As  a 
result,  similar  projects  tended  to  maintain  this  equilibrium 
so  that  as  the  systea  size  increased,  the  developaent 
schedule  Increased  correspondingly.  This  equilibrium  also 
maintained  the  staffing  rate. 
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2 

K/t  , 
d 


(2 


within  bounds  that  could  be  effectively  accommodated  by  the 
project.  Thus,  he  used  this  equilibrium  expression  to 
define  system  complexity  (0)  as 


D  *  K/ 


(2.20) 


The  value  of  D  can  be  thought  of  as  a  limiting 
parameter  in  determining  the  minimum  development  time  that 
an  organization  can  achieve  for  a  given  software  project. 
Table  III  shows  the  values  of  D  determined  by  Jensen  from 
Putnam's  analysis  of  (JSACSC  data. 

The  next  equation,  developed  by  Jensen,  was  referred 
to  as  the  software  equation,  relating  the  size  of  the  system 
to  the  technology  being  applied  by  the  developer  in  the 
implementation  of  the  system.  In  deriving  this  equation, 
Jensen  utilized  an  extension  of  the  productivity  relation¬ 
ship  proposed  by  a.  F.  Sampson  of  General  Electric  Company. 

Sampson  [22],  after  reviewing  data  supplied  by 
Putnam  from  19  OSACSC  projects,  determined  that  only  a 
subset  of  these  projects  represented  a  consistent  develop¬ 
ment  environment  and  were  sufficiently  documented  to  be  of 
value  in  establishing  the  model  parameters.  Evaluation  of 
this  refined  set  of  data  obtained  a  B  value  of  -0.50  for  the 
basic  relationship  between  productivity  and  project  stress 
instead  of  the  -0.667  obtained  when  all  the  data  was  used. 

*  Pith  Sampson's  work  in  mind,  Jensen  derived  the 
software  equation  to  establish  the  rate  of  source  code 
development,  dSs/dt.  In  his  development,  he  assumed  that 
the  portion  of  the  project  effort  devoted  to  code  produc¬ 
tion,  P1(t),  was  characterized  by  a  Rayleigh  curve,  which 
was  complete  at  td. 


37 


TABLE  III 


Ills* 


Applies  to  new  systems  with  significant  inter¬ 
face  and  interaction  requirements  within  a  lar¬ 
ger  system  structure,  operating  system  and  rea 


ystem  structure,  operating  systea 
processing  developments  with  large 
of  logical  code  are  typical  of  thi 


time  proces 
ages  of  log 
of  systems. 


a  and  real 
e  percent- 
is  class 


with  the  underlying  operating  system  or  other 

?arts  of  the  system  is  minimal.,  Hew  applica- 
ions  software  is  typical  of  this  class  of  sys¬ 
teas. 

Applies  to  complete  rebuilds  of  existing  stand¬ 
alone  systeas  where  major  portions  of  existing 
logic  can  be  used . 

Applies  to  composite  systems  where  existing  sys- 
tens  are  combined  or  integrated  with  little  or 
no  modification  of  existing  software. 


Then  if 


t  /t  1  -  6f 
d  d 


(2.21) 


where 

t  1  »  the  tiae  of  peak  aanloading  on  the  Rayleigh 
d 

curve,  coincidental  to  development  '  ime,  and 

/d  fa  2  -  (3 1  /t  ) 

P  (t)  dt  *  J  (K/t^)te  d  dt  *  0.5.  C/6 ,  (2. 22) 

then  the  burdening  rate  for  this  project  is 


P(t)  dt 


PI  (t)  dt 


0.3934K 


0.95K/6 


2.49, 


(2.23) 


where 


P  (t)  *  staffing  level.  The  rate  of  source  code  devel¬ 
opment,  dSs/dt,  is  assumed  to  be  proportional  to  the  rate  of 
code  production,  PI  (t)  so  that 

Ss  *  2.49  PH  P1(t) , 

and 

2  2 

—  2  /•"  -  (3t  /t  ) 

Ss  *  2.49  PH  K/t^  J  te  d  dt  (2.24) 

=  2.49PR  K/6 . 

_  -0.5 

Substituting  the  empirically  derived  value  of  PR  *  C^M 


giv  es : 


.  5 

Ss  *  (2.49C  /6)K  t  , 
I  d 


or 


Ss  a  c  VF  t,  , 
t  d 


(2.25) 


which  is  the  software  equation  where 

«  a  developer  technology  constant. 


This  technology  constant,  Ct,  is  a  factor,  or 

constant  of  proportionality,  that  allows  the  user  to  relate 

the  system  size,  Ss,  the  life  cycle  effort,  K,  and  the 

development  time,  t  ,  for  any  specified  project.  The 

d 

constant  accounts  for  all  variations  in  the  life  cycle 
effort  for  projects  which  have  similar  size  and  schedule 
properties.  The  constant  is  then  a  measure  of  the  develop¬ 
er’s  production  technology,  or  ability  to  implement  the 
project.  This  includes  such  factors  as  the  availability  of 
computing  resources,  organizational  strategies,  development 
tools  and  methodologies,  familiarity  with  the  target 
computer,  etc. 


The  technology  constant  considers  two  aspects  of 
production,  the  environmental  aspect  and  the  technical 
aspect.  The  environmental  aspect  includes  those  factors 
dealing  with  the  basic  computing  environaent.  The  environ¬ 
mental  factors  deteraine  a  technology  constant  which 
noraally  ranges  between  2000  and  5000,  with  higher  values 
characteristic  of  higher  productivity  environments;  ie., 
from  primitive  tools  to  dedicated  advanced  tools  and 
resources.  The  technical  aspects  of  the  technology  constant 
are  accounted  for  through  the  use  of  adjustment  factors 
applied  to  the  basic  technology  constant  by  use  of  the 
formula 


C 

t 


c 


tb 


f 

i 


c 

tb 


(2.26) 


where 


C  =  basic  technology  constant, 
f.  ■  ith  adjustaent  factor,  and 
f ^  »  total  adjustaent  factor. 

The  adjustment  factors  include  those  effects  which  are 
beyond  the  basic  development  environment  and  are  project 
specific.  The  factors,  which  are  shown  in  Table  IV,  are 
examples  of  those  found  in  a  command  and  control  system 
environaent. 


Feeling  that  his  model  could  be  understood  better  as 
a  linear  programming  problem  presented  in  a  graphical 
format,  Jensen  defined  the  additional  formulas  which  he 
could  use  for  this  forum.  The  first  formula  was  for  the 
development  effort  (E)  which  he  derived  as: 


E 


P  (t)  dt  =  0. 4K. 


(2.27) 
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Factor 

Value 

Number 

Description 

Tes  1 

No 

1 

Special  display  requirements 

1.11 

2 

Detail  operational  requirements 

1.00 

1.54 

3 

Changes  to  operational  require¬ 
ments 

1.05 

1.00 

4 

Beal  time  operation 

1.33 

1.00 

5 

CPU  memory  constraint 

1.25 

1.00 

6 

CPU  time  constraint 

1.51 

1.00 

7 

Pirst  software  developed  on  CPU 

1.92 

8 

Concurrent  &DP  hardware 
development 

1.67 

1.00 

9 

Developer  using  computer  at 
another  facility 

1.43 

1.00 

10 

Development  at  operational  site 

1.39 

1.00 

11 

Development  computer  different 
than  target  computer 

2.  22 

1.00 

12 

Development  at  multiple  sites 

1. 25 

1.00 

13 

First  use  of  language 

1.80 

1.00 

14 

NIL- STD  documentation 

1.40 

1.00 

The  next  was  a  relationship  (B)  determined  by  the  system 
size  and  the  developer's  approach  to  the  project  and  was 
given  by: 

B  »  Ss/C^  =  .  (2.29) 

Then,  utilizing  the  formulas  for  N  and  D,  equations  (2.17) 
and  (2.20),  where  H  represents  a  fixed  staffing  rate  or 


management  stress  curve,  and  0  raprasants  projects  of  fixed 
complexity,  ha  coaid  plot  all  these  aquations  on  a  solution 
surface  for  various  size  projects  as  shown  in  Fiqure  (2.3). 


Figure  2.3  Bacro- Estimating  Bodel. Solution  Surface 

(Graphical  Hap  rase  ntation) 


For  exaaglg,  as suae  a 


D  »  15.  for  laplementat 
be  treated  as  being  aore 
it  can  never  be  treated  a 
defined  by  0<D  <  15  i 

solution  space.  The  sa 
with  the  paraaeters  Ss  an 
the  ratio  H  *  Ss/Ct  *3 
region,  30  £  R  <  *  ,  is  d 

20  defines  a  region  0  < 
always  be  used  than  is 
intersection  of  the  R 
determines  the  ainiaua  de 
resulting  feasible  reg 
Secondary  constraints  o 
development  effort  can  al 
solution  region, [23] 


project  is  defined  with  a  value, 
ion  considerations,  a  project  can 
complex  than  it  actually  is,  but 
s  being  simpler;  thus,  the  region 
ust  be  considered  as  a  feasible 
me  type  of  reasoning  can  be  used 
d  ct  in  the  R  curve,  so  that  if 
0,  is  specified,  the  feasible 
erined.  Similarly  a  value  of  s  3 
H  <  20,  since  less  staff  can 
available,  never  more.  The 
and  D  curve  or  R  and  M  curve 
velopaent  time,  depending  on  the 
ion  mapped  by  three  curves, 
f  development  time,  td,  and 
so  be  used  to  define  the  *«asible 


With  respect  to  either  effort  or  time,  the  optimum 
solution  will  be  located  at  one  of  the  vertices  defined  by 
the  constraint  lines.  The  possibility  exists  that,  once  all 


the  constraints,  D,  B,  H,  E,  and  t  ,  are  plotted  on  the 

d 

solution  surface  as  shown  in  Figure  (2.4),  sone  of  the 
constraints  will  be  eliminated  froa  futher  analysis  by  the 
Banner  in  which  other  constraints  intersect  to  fora  the 
bounded  region.  If  the  constraints  bound  a  null  region, 
either  the  cost  or  schedule  is  too  optiaistic  and  cost  or 
schedule  overruns  in  software  development  are  likely  to 
occur.  However,  by  utilizing  the  values  for  K  and  t 

d 


Figure  2.4  Feasible  Solution  Region 


obtained  froa  the  graph  and  substituting  into  the  Rayleigh 
equation,  the  optima  staffing  profile  (T*)  can  be  obtained. 

Recognizing  that  the  calculations  made  by  the  model 
assume  that  the  input  parameters  are  exactly  known,  and  that 
there  is  a  degree  of  uncertainty  associated  with  each  of  the 


input  parameters,  Jensen  postulated,  for  risk  analysis,  that 
the  deviation  froa  the  mean  can  be  calculated  using  the 
relationship 

22  22  2205 

of  *  [  Of/aSs)  o  ♦  (3f/8C  )  o  ♦  ( df/dD)  a  ]  *  , 

s  t  C  D 

where 
f 

or 

3  0.4 

f  ■  K  ■  [  (Ss/C^)  D]  .  (2.29) 

Similar  expressions  for  f  could  be  found  by  using  H, 
instead  of  D,  as  the  bounds  for  the  feasible  region.  In 
cases  where  both  M  and  D  interact,  the  expression  for  f 

should  be  considered  invalid  and  no  alternative  solution  was 
provided.!  24  ] 

As  an  example  of  this  risk  analysis  technique  he 

provided  the  example  where  Ss  «  55,642;  D  *  15;  s  *  2,058; 

o  *  1;  and  t  *  0.482.  The  results  were  then  plotted  as 
D 

shown  in  Figure  (2.5).  The  results  show  that  the 
probability  of  meeting  the  required  schedule  is  94 

percent.! 25  ] 

2 •  Other  Models 

A  description  of  some  additional  models  which  were 
not  used  in  this  thesis  but  the  reader  might  find  informa¬ 
tive  are  provided  in  Appendix  A  and  Appendix  5,  as  described 
by  R.  Thibodeau  and  R.  W.  Wolverton,  respectively  [26,27]. 

C.  CHAPTER  TBO  SUMMARY 

The  thesis  of  the  models  used  in  this  chapter  and  in 
others  that  were  found  in  the  literature,  was  to  try  and 
give  management  a  tool  with  which  they  could  predict  the 

cost  of  software,  the  time  for  producing  this  software. 


V5/ ( Ss/C^)  1/D, 


or 


OEVELOfMENT  TIME,  MONTHS  ^  | 

Figure  2.5  Bisk  Analysis  of  Schedule  Using  Graphical 
Technique 

both.  Host,  if  not  all  of  the  models  require  the  use  of 
historical  data  and/or  management's  previous  experience  as  a 
portion  of  the  predictive  process. 

It  was  Putnam's  view  that  software  production  followed  a 
Bayleigh  curve.  This  curve,  he  asserted  could  be  calculated 
utilizing  historical  data  to  deteraine  the  technology 
constant  (Ck)  ,  and  the  estimate  of  source  lines  of  code  for 
this  type  of  project  (Ss)  ,  plus  the  budgeting  information 
for  the  total  number  of  man-years  for  the  systems  life 
cycle. 

The  Army  Hacro  model  utilized  Putnam*  s  technique,  but, 
at  various  time  increments,  would  compare  actual  results 
with  those  predicted  and,  if  the  actual  resources  expended 
were  statistically  outside  some  preset  control  limits, 
corrective  action  would  be  taken. 


Parr  felt  that  Putnaa' s  aodel  did  not  take  into  account 
the  effort  that  was  completed  prior  to  the  actual  starting 
date.  He,  therefore,  proposed  a  aodel  which  would  take  this 
work  into  account  in  the  early  part  of  the  project.  It  also 
correlated  well  with  the  work  done  by  Norden  and  Putnaa  with 
the  Hayleigh  curve,  both  at  the  peak  level  and  in  the  later 
stages. 

Lehaan  and  Belady  found  in  their  study  of  the  evolution 
cf  the  OS/360  operating  systea  prograaaing  effort  that,  as 
the  size  and  coaplexity  of  each  release  which  contained 
functional  enhanceaents  increased,  so  did  the  nuaber  of 
errors  and,  thus,  the  aaount  of  aaintenance  effort  also 
increased.  Therefore,  they  postulated  that  for  any  systea 
there  is  a  tiae  when  it  is  better  to  restructure  and  consol¬ 
idate  than  to  continue  with  additional  enhanceaents. 

Jensen  felt  that  Putnaa 's  aodel  required  sone  expansion 
and  refineaent.  This  he  atteapted  to  acconplish  through  the 
use  of  linear  prograaaing  and  graphical  representation  of 
his  results. 


x’t.  aiaiauaa  caai  &siiamas  m  tas 


Mi 


The  Green/Selby  aodel  includes  two  techniques:  the  first 
characterized  by  a  aacro  approach  and  the  second  by  a  aicro 
approach.  The  results  of  the  application  of  both  techniques 
to  project  planning  paraaeters  are  coapared  and  then  weighed 
against  aanagerial  and  organizational  constraints  to  analyze 
tradeoffs  and  produce  cost  estinates. 

A.  NACBG  APPROACH 

The  aacro  approach  is  concerned  with  nan-loading  across 
the  life  cycle  of  the  project  and,  in  particular,  the  nain- 
tenance  phase.  The  basis  for  this  approach  is  derived  fron 
the  relationships  pioneered  by  Morden  and  further  developed 
by  Putnaa.  As  was  stated  in  chapter  two,  the  various  phases 
of  the  software  project  life  cycle  have  been  found,  in 
general,  to  be  characterized  by  the  Rayleigh  curve  function. 
The  function  is  written  as  follows: 


where 


2  Kate 


(3.1) 


a  nanloading  at  any  tine  t,  nor  sally  measured  in 
nanyears  or  sanaonths, 

»  elapsed  tise  fro  a  the  start  of  the  project, 

*  the  total  accumulative  manpower  utilized  over  the 
project  life  cycle,  measured  in  manyears  or 
manmonths, 

and 

*  the  shape  parameter  of  the  curve. 


f 


Nor  den  demonstrated  that  the  shape  parameter  (coefficient), 
a,  can  be  calculated  by  the  equation: 


(3.2) 


where 

t  *  the  point  in  tiae  of  aaximua  manpower  utilization 
d 

for  the  project. 

It.  must  be  noted  here  that  t  in  equation  (3.2)  can,  in 

d 

large  projects  (defined  by  Putnam  as  those  projects  with 

about  75,000  source  lines  of  code  [28]),  be  equated  to 

project  development  tiae.  In  other  words,  large  projects 

have  historically  been  characterized  by  maximum  aanloading 

at  the  end  of  the  development  phase,  roughly  when  the 

product  was  delivered  to  the  user.  However,  it  has  been 

found  empirically  [29]  that  for  other  than  large  projects 

(less  than  75,000  source  lines  of  code)  t  actually  falls  at 

d 

some  point  between  t  and  the  end  of  the  development  phase. 

This  may  or  may  not  affect  the  Green/Selby  model.  The  end 

of  the  development  phase  will  be  denoted  as  t  ,  if  it  in 

dev 

fact  does  not  coincide  with  t  .  Putnam  has  indicated  that 

d 

for  small  projects  (less  than  18,000  source  lines  of  code) 

Y'  is  reached  at  about  t  /V^TI  Hedium  sized  projects 

Sax  dev 

,000  -  75,000  source  lines  of  code)  reach  Y*  somewhere 
_  max 

between  t  /Vo  and  t  /2.  [30]  Therefore,  t  ,  in  this 
dev  dev  d 

thesis,  will  be  defined  as  the  tiae  at  which  Y'  reaches  a 

maximum. 


Substituting  equation  (3.2)  into  equation  (3.1)  gives 
the  fallowing  equation: 


XA  te 


2  2 
-t  /2 1 

d 


(3.3) 


This  equation  can  be  ased  to  calculate  Y*  at  any  point  on 

the  curve  once  K  and  t  are  known.  The  calculation  or  esti- 

d 

nation  of  K  and  t  have  been  sufficiently  dealt  with  in  the 

d 

literature  and  so  they  will  not  be  addressed  here  [31]. 
However ,  it  aust  be  noted  that  t  =  t  at  the  point  of 
■axiaua  aanloading,  and  so,  at  that  point,  equation  (3.3) 
breaks  down  to: 

-1/2 

Y*  =  K/t  9.  (3.4) 

max 

Horden  also  stated  that  the  Rayleigh  curve  exhibited  an 
inflection  point  where  the  decrease  in  manpower  usage  slows 
down  in  the  descending  portion  of  the  curve  [32],  as  charac¬ 
terized  by  the  equation: 

1/2  ,  „ 
t  *  (3/2a)  ,  (3.5) 

ip 

where 

t  *  the  tine  of  the  inflection  point  of  the  Rayleigh 

ip  , 

curve,  and 

a  *  the  curve  shape  parameter 
The  Green/Selby  model  is  based  in  the  theory  that  Y* 

tlD 

can  be  defined  as  a  maximum  level  of  maintenance  effort  for 

a  project.  The  minimum  level  of  maintenance  effort  is 

defined  by  Y*  ,  the  inflection  point  on  the  curve  for 

tie 

the  maintenance  phase,  which,  for  large  projects  in  general, 

has  been  said  in  the  literature  to  follow  the  Rayleigh 

pattern.  The  definition  of  t,  as  a  maximum  level  of  mainte- 

x  p 

nance  was  further  supported  by  the  hypothesis  that  the 
maximum  level  of  aanloading  during  the  maintenance  phase, 

Y'  ,  was  equal  to  the  aanloading  at  the  inflection  point 

t  a 

Y*  •  This  hypothesis  appears  to  be  based  on  the  assumption 
tip 

that  the  maximum  point  of  the  maintenance  phase  coincides 


both  in  tine  and  in  magnitude  with  the  inflection  point  of 
the  life  cycle  curve.  Green  and  Selby  used  the  empirical 
data  synthesized  from  a  spectrum  of  OSACSC  projects  to 
develop  the  theory.  Figure  (3.1)  depicts  their  theoretical 
model. 


with  work  breakdown  structures  to  project  maintenance 
manning  requirements.  The  raw  data  was  synthesized  by  Green 
and  Selby  to  fit  the  aacro  model  and  then  compared  with  the 
results  of  the  micro  matrix  method.  The  authors  of  this 
thesis  were  not  able  to  obtain  data  of  sufficient  complexity 
and  refinement  to  apply  micro  techniques  to  it,  and,  there¬ 
fore,  the  micro  approach  will  not  be  discussed  further  in 
this  work. 

C.  PROJECTED  BODEL  APPLICATIONS 

The  Green/Selby  model  was  presented  as  a  management 

tool.  The  control  concept  coupled  with  the  planning  concept 

appeared  to  be  a  total  maintenance  strategy  package  for  the 

project  manager.  The  model  could  provide  management  with  the 

determination  of  a  maintenance  support  level  by  use  of  the 

inflection  point  predictors  (!'  .  and  Y*  )  to  define 

tip  tim 

maximum  and  minimum  maintenance  manpower  utilization  bounda¬ 
ries.  These  boundaries,  coupled  with  a  planning  strategy, 
provide  a  powerful  planning  tool. 

Use  of  the  model  was  also  projected  for  forecasting  of 
resource  distribution  via  integration  techniques  applied  to 
the  area  of  the  curve  under  the  maintenance  support  boundary 
to  break  out  manpower  required  by  separation  of  development 
work  (enhancements,  additions,  new  design)  from  pure  mainte¬ 
nance  work  (debugging,  design  error  correction)  .(  33] 

The  model  was  finally  projected  as  a  device  for  moni¬ 
toring  configuration  control.  Drawing  on  the  work  of  Lehman 
and  Belady,  Green  and  Selby  theorized  that,  as  a  project 
moves  from  pure  "fix-it"  type  maintenance  to  modifications 
which  may  eventually  lead  to  a  new  release  of  the  product, 
the  complexity  of  the  product  increases.  This  rise  in 
complexity  increases  the  maintenance  level.  As  successive 
releases  are  developed,  the  maintenance  level  increases 


until  it  eventually  exceeds  the  origin.',  maximum  maintenance 
support  level  of  the  product.  Th^  would  then  predicate 
management  assessment  of  the  viability  of  the  project  from  a 
cost  effectiveness  point  of  view,  as  the  project  will  have 
reached  what  Green  and  Selby  called  a  maintenance  budget 
saturation  point.  At  this  point,  or  earlier,  depending  on 
management  policies  and  desires,  the  old  project  would  be 
terminated  and  a  new  life  cycle/Rayleigh  curve  started. 

D.  CHAPTER  THREE  SOMflARY 

The  Green/Selby  model  appears  to  provide  an  easy-to-use 
cost  estimation  tool  for  the  data  systems  manager.  The  macro 
and  micro  approaches  give  fairly  quick  estimates  of  mainte¬ 
nance  manloading  which  can  be  cross  compared  and  coupled 
with  management  constraints  to  fill  out  the  system  manager’s 
overall  strategy.  If  valid,  it  seems  to  partially  fill  the 
void  in  data  systems  management,  alluded  to  in  the  GAO 
report,  that  of  the  lack  of  a  maintenance  strategy  in  an 


IV.  MOD  EL  VALIDATION 

A  mathematical  development  of  the  Green/Selby  model  was 
completed  by  the  authors  of  this  thesis  solely  by  algebraic 
substitution  and  reduction,  working  with  the  basic  equations 
and  relationships  from  the  works  of  Nor den  and  Putnam.  An 
empirical  development  of  the  model  was  completed  using  the 
same  or  similar  data  to  that  used  by  Green  and  Selby.  Both 
developments  follow. 

A.  MATHEMATICAL  DEVELOPMENT 

The  Norden/Hayleigh  curve  equation,  as  discussed 
earlier,  is: 

2 

-at 

Y*  *  2 Kate  .  (4.1) 

This  equation  is  characterized  as  a  two  parameter  equation, 

as  the  outcome  hinges  on  two  parameters,  K  and  a,  calculated 

across  the  life  cycle  for  all/any  times  from  t  to  t  . 

0  n 

The  parameter,  a,  as  used  in  the  Green/Selby  model,  is 
calculated  by: 


2 

a  »  1/2t  .  (4.2) 

d 


The  Green/Selby  Model  appears  to  have  been  developed  for 

large  projects  with  the  assumption  that  t  and  t  do 

dev  d 

coincide.  Therefore,  if  a  is  substituted  into  the 
Nor  den/  Rayleigh  equation,  the  commonly  used  fora  is  found: 


53 


which  farther  reduces  to 


Y*  »  1.73K/t  *e 
t  d 

ip 


-3/2 


(4.6) 


In  the  Green/Selby  Model,  it  is  theorized  that  the 

inflection  point  of  the  life  cycle  curve  and  the  point  of 

Y'  on  the  curve  for  the  aaintenance  phase  coincide.  The 
nax 

tines  t  and  t  are  the  sane  absolute  tine;  however,  for 
ip  n 

purposes  of  calculations,  they  differ,  since  t  ,  the  naxiaun 

a 

nanning  for  the  naintenance  curve  is  calculated  relative  to 

the  start  tine  for  naintenance  or  the  t  for  the  naintenance 

0 

curve.  If  developaent  tine  is  equal  to  t^,  as  was  assuned  in 

the  Green/Selby  Model,  and  if  the  aaintenance  effort  starts 

at  t  ,  then  the  t  for  the  naintenance  curve  is  t  for  the 
d  0  d 

life  cycle  curve.  Figure  (4.1),  with  a  corresponding  tine 

line,  deaonstrates  the  general  relationship. 

Green  and  Selby  symbolized  the  elapsed  tine  t  to  t  as 

0  n 


t  -  t  . 
n  0 


(4.7) 


It  is  at  this  juncture 

nent  arises.  The  difficult 

the  naintenance  phase  begin 

development  phase  ends  as 

sonetine  after  that?  The  ti 

paraneter,  a,  depend  on  t 

using  Amy  Data,  stated  th 

nance  phase  began  at  tine 

tine  (t  ♦  0. 3t  ).  Therefor 
d  d 

nance  curve  projection,  or 
(4.2)  and  equation  (4.8)  be 


that  difficulty  in  the  develop- 

y  lies  in  the  definition  of  where 

s.  Does  it  begin  at  t  when  the 

dev 

in  Figure  (4.1),  or  does  it  begin 

ne  to  Y'  and  thus,  the  shape 
nax 

hat  definition.  Green  and  Selby, 

at,  on  the  average,  the  mainte- 

1.3  with  t  normalized  to  1  or 
d 

e,  the  estimate  of  t  for  aainte- 

d 

t  ,  will  be  as  shown  in  Figure 
e 

low. 


Figure  4.1  Haintenance  Phase  Tiling  Relationships 


The  estiaate  of  K  for  the  aaintenance  phase  also  caae 
froa  the  iray  data  which  indicated  that,  on  the  average,  the 
K  for  the  aaintenance  phase  is  20  percent  of  lifecycle  K  or 
0.2  K  (lifecycle)  with  lifecycle  K  normalized  to  1. 


Figure  4. 2  Maintenance  Phase  Tiling  Relationships  in 
the  Green/Selby  Model 


Since  it  is  theorized  that  t 

i 

Figure  (4.2)  that 


t  ,  it  can  be  seen  froi 
ip 


'e 


0. 3t 


(4.9) 


It  east  be  noted  here  that  this  development,  because  of 
the  nature  of  the  problem  and  the  lack  of  firm  data,  cannot 
be  a  pure  mathematical  development;  however,  the  attempt  is 


■ade  to  approximate  it  as  closely  as  possible.  Even  though 

the  t  ,  or  time  of  T*  ,  in  the  equations  for  the  life 
d  max 

cycle  and  maintenance  curves  denote  the  same  type 

relationship  within  their  parent  equation,  the  quantities 

are  necessarily  different,  is  far  as  the  authors  know,  and 

it  is  projected  that  the  case  was  the  same  for  Sreen  and 

Selby,  no  specific  relationship  between  t  (lc)  and  t  (a) 

d  d 

have  been  found  empirically.  Therefore,  for  this  development 
to  exhibit  credibility,  known  estimation  factors  from  the 
Army  data  must  be  introduced.  This  also  tends  to  indicate 
that  until  some  firm  relationship  between  t^'s  is  found, 
general  applicability  will  be  lacking.  The  same  applies  for 
the  K  factor. 

After  substituting  the  value  for  t.  from  equation 

xp 

(4.5),  equation  (4.8)  becomes: 


t 

e 


(t  ♦  0. 3t  ) 
d  d 


0. 43t  .  (4.9) 
d 


Substituting  the  value  for  t  (maintenance  phase  t  ) 

e  d 

equation  (3.4)  for  the  I*  of  a  curve  gives: 

ma  x 

-1/2 

I*  *  K/t  *e, 
t  e 


into 


which  reduces  to 

-V2 

T»  *  0. 2K/0. 43 1  *9  .  (4.10) 

t  d 

a 

The  constant  e(-3/2),  in  equation  (4.6),  is  calculated  to  be 
0.2  23,  and  the  constant  e(-1/2)  above  is  calculated  to  be 
0.507.  They  are  substituted  into  equation  (4.6)  and  (4.10) 
respectively  to  give: 

T«  *  1.7  3K/t  *0.  223  or 

t  i 

ip 


58 


and 

I*  *  0.38 6K/t 

t  d 

ip 

Y*  «  0.  2K/0.43t  *0.607 

t  d 

m 

I*  *  0.  121  K/0.43t  . 

t  d 

a 

Attempting 

to  equate  Y'  to  Y*  produces 

ip  m 

0.386K  0.1 2 1 K 

Algebraic  reduction  carries  the  development  to  completion 

0- 43t  0.121K 


t  0. 386K 


which  gives 


0.43  *  0.121/0.386 


0.43*0.313. 


(4.14) 


A  sisilar  development  using  K's  and  t  's  alone  without  the 

d 

relational  factors  taken  from  Army  project  experience  gives 

similar  results.  This  is  significant  since  it  indicates 

that,  for  large  projects  where  life  cycle  t  »  t  ,  the 

d  dev 

manloading  at  the  maximum  point  on  the  maintenance  curve  is 
not  necessarily  equal  to  the  manloading  at  the  inflection 
point  on  the  lif9  cycle  curve.  There  are  situations  where, 
theoretically,  with  the  right  values  for  t  ,  t  ,  and  the  two 

U  8 

K's,  !'  and  T'  will  be  equal,  but  it  becomes  apparent 
tip  tm 

that  no  such  general  rule  can  be  demonstrated.  Therefore, 
the  proof  of  applicability,  as  has  been  the  case  in  all 


areas  of  software  cost  estimating  research  so  far,  falls 
back  into  the  arena  of  eapirical  development.  The  empirical 
development  used  by  Green/Selby  follows  in  section  B. 

B.  EMPIRICAL  DEVELOPMENT 

The  present  authors,  in  recreation  of  the  Green/Selby 

model,  developed  it  as  follows. 

All  parameters  were  normalized  to  values  of  t  and  K 

d 

equal  to  1.  With  t  *  1  and  equation  (4.2)  calculate  a: 

d 


a  *  1/2t  *  0.5. 

d 


(4.15) 


Substitute  a  into  equation  (4.4)  and  calculate  t  : 

ip 


t,  *  (3/2a)  *  1.73  years, 

ip 


(4.16) 


Substitute  t  into  equation  (4.6)  to  calculate  T* 

iP  * 


-a  (t  ) 

Y*  *  2Kat  e  ip  ,  and 
t  ip 

ip 


-0.5(1.73) 

I*  __  *  2(1)  (0.5)  (1.73)  e  ,  and 

1  •  f  J 


y*  *  0.387  aanyears. 
1.73 


(4.17) 


To  equate  maximum  maintenance  aanloading  to  the  life  cycle 
inflection  point,  define  the  time  of  maximum  maintenance 

as  t  .  Thus, 

a 


(4.  18) 
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O.S.  Army  Computer  Systems  Command  project  data  indicated 

that,  across  the  spectrum  of  Army  software  projects,  the 

maintenance  phase  included  about  20  percent  of  the  life- 

cycle.  Therefore,  K  for  the  maintenance  phase  is  0.2K  with 

respect  to  the  normalized  life  cycle  K  value  of  1.  Here,  it 

must  be  assumed  that  Army  data  analysis  is  valid.  However, 

it  is  the  contention  of  the  authors  of  this  thesis  that  an 

average  of  all  Army  large  scale  software  projects  will  give 

a  good  figure  for  k/t  for  their  types  of  projects.  Army 

d 

data  also  indicated  that  the  maintenance  phase  started  at 


1.3  years  normalized  time  (t  )  .  If  Y*  *  Y*  at  t  , 

0  tip  tm  ip 

then,  making  the  same  assumption  as  Green/Selby,  that 

t  *  t  ,  the  time  of  maximum  maintenance  manloading  ,  t  , 
ip  n  e 

can  be  calculated  by: 

t  -  t  *  t  ,  and 
n  0  e 


1.73  -  1.3  *  0.43  years. 


(4.19) 


Calculate  a  for  the  maintenance  curve  from  equation  (4.2): 

m 


a  «  1/2t  *  2.71. 

m  e 


(4.  20) 


Substitute  a  and  t  into  equation  (4.1)  to  calculate  Y*  : 

e  t 

m 


-(a  (t  )) 

Y'  *  2Ka  t  e  me  , 
t  me 

m 


-  (2.71  (0.43  )) 

Y*  *  2  (0. 2K)  (2.71)  (0.43)  e  ,  and 


0.2824. 


(4.21) 


Ose  equation  (4.4)  to  calculate  t 


t  *  (3/2a)  *  0.74  years. 

ia 


(4.22) 


The  maintenance  curve  inflection  point,  t.  ,  on  a  life 
cycle  basis,  normalizes  to  2.04  years,  substitute  t  into 
equation  (4.6)  to  calculate  Y'  : 


-(a  (t  )) 

I*  *  2Ka  t  e  a  ia  , 

t  a  ia 

ia 


-(2.71)  (0.74  ) 

Y*  »  2(0. 2K)  (2.71)  (0.74)e  ,  and 

”ia 


*  0.182. 


(4.23) 


The  noraalized  curve  as  developed  above  is  depicted  in 
Figure  (4.3). 

Here,  Y*  is  clearly  not  equal  to  Y* ^  ,  as  was  also 
found  in  the  mathematical  developaent,  but  rather,  Y*  is 

u  fl 

about  25  percent  less  than  Y*  in  aagnitude,  when  t  and 

tip  a 

t  coincide, 

ip 


C.  CHAPTER  FOUR  SOHHAHY 

In  both  the  aatheaatical  developaent  and  the  eapirical 
developaent,  aaziaua  manloading  for  the  maintenance  phase 
and  aanloading  at  the  inflection  point  of  the  life  cycle 
curve  were  not  found  to  be  equal.  However,  the  maintenance 
aaxiaua  was  below  the  aagnitude  at  the  inflection  point. 


Figure  *.3  Developed  Normalized  carve 


Therefore,  though  the  Green /Selby  theory,  in  itself,  nay  not 
be  substantiated,  some  relationship/s  may  exist  which  can  be 
used  for  maintenance  manpower  estimates.  The  key  relation¬ 
ships  in  any  maintenance  manloading  estimates  appear  to  be 


those  of  life  cycle  K  versus  maintenance  K  and  life  cycle  t 

d 

versus  maintenance  t  .  If  some  empirical  relationship  (such 

as,  for  all  large  projects  maintenance  t  is  X  percent  of 

d 

life  cycle  t  or  maintenance  K  is  X  percent  of  life  cycle  K) 
d 

can  be  determined,  then  a  model  development  could  possibly 


be  completed  which  produces  fairly  accurate  manloading  esti¬ 


mates.  Such  a  model 

Y*  but  rather  some 

t  a 

overall  army  project 


would  not  necessarily  hinge  on  Y*  = 

relationship  such  as  that  exhibite^by 

data  where  Y*  or  maximum  average 
tm 
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■ai nt enance  level  fell  at  about  75  percent  of  !'  ,  .  The 

tip 

difficulties  encountered  in  atteapting  to  develop  the  theory 
aathesatically,  in  respect  to  ifferences  in  K*s  and  t  *s, 

a 

suggest  that  there  say  be  other  factors  affecting  the 
relationships  and  the  paraaeters  that  deter aine  those 
relationships.  Such  factors  are  discussed  in  Chapter  71. 


v.  BSSfiASSB  Mitim 


A.  DATA  DEFINITION 

The  data  utilized  in  the  research  effort  was  received 
froa  two  sources,  NASA  Goddard  Space  Flight  Center, 
Greenbelt,  fld.,  and  Dr.  Villa  Ehrlich,  Bankers  Trust  Co., 
NY.,  NY.  Both  sets  of  data  consisted  of  aanloading  for  soft¬ 
ware  projects  over  the  life  cycle  and  included  aaintenance 
data.  Hanpower  utilization  figures  were  in  manhours  for  the 
NASA  data  and  aanaonths/ath  for  the  Bankers  Trust  data.  The 
NASA  data  was  converted  to  aanaonths/ath  prior  to  analysis. 
The  projects  analyzed  will  be  called  NASA  project  and 
Projects  A-D  for  the  purposes  of  this  thesis. 

1.  Baa&gsa  Hast  £2 •  Sals 

Projects  A-D  were  all  medium  sized  projects,  devel¬ 
oped  at  Bankers  Trust  Company.  The  few  project  character¬ 
istics  that  were  known  can  be  found  in  Table  V.  A  listing  of 
project  data  by  aanaonths/ath  is  found  in  Appendix  C. 

2.  NASA  data 

NASA  project  data  were  related  to  an  operational 
system  and,  though  it  is  an  ongoing  project  and  the  complete 
life  cycle  is  not  yet  known,  much  information  could  be 
synthesized  froa  the  life  cycle  and  maintenance  data  to 
date.  Pertinent  project  characteristics  are  listed  in  Table 
VI.  It  is  readily  apparent  that  the  project  started  as  a 
small  project,  but  that  it  has  migrated  via  aaintenance  to 
what  could  be  called  a  large  project.  However,  based  on 
project  size  at  the  end  of  development,  it  must  be  classi¬ 
fied  as  a  small  sized  project.  A  listing  of  project  data  by 
aanaonths/ath  is  found  in  Appendix  C. 


B.  ANALYSIS  PROCESS 


The  analysis  process  fell  into  two  categories,  curve 
fitting,  and  comparison.  Actual  life  cycle  manmonth  figures 
for  individual  projects  were  fitted  against  the  Rayleigh 
equation  via  the  facilities  provided  for  non-linear  curve 
fitting  in  the  statistical  Analysis  System  (SAS)  package 
available  on  the  resident  IBB  3033AP  Coaputer  System.  The 
Marquardt  method  was  chosen  as  the  regression  technique.  In 
addition,  data  from  the  four  Bankers  Trust  Co.  projects  were 
combined  by  normalizing  t^  (the  time  to  reach  1'  >  to  1 
for  each  project  and  then  the  curve  fitting  techniques  were 
applied  to  the  normalized/ combined  data.  Manpower  figures 
for  the  maintenance  phases  of  individual  projects  and  the 
combined  data  were  also  fitted  to  the  Rayleigh  equation  and 
then,  in  each  situation,  actual  data  points  and  fitted 
curves  for  life  cycle  and  maintenance  phases  were  replotted 
on  a  common  axis  to  provide  an  aggregate  picture  of  the 
phase  relationships. 

The  OSACSC  data  was  also  reanalyzed.  Though  it  did  not 
provide  substantiation  for  the  specific  theory  of  Sreen  and 
Selby,  as  noted  in  chapter  four,  it  does  provide  valuable 


insight  into  the  phase  relationships  as  applied  to  large 

sized  projects.  A  mass  of  raw  data  was  not  available,  but  by 

taking  the  aggregate  figures  provided,  critical  points  along 

the  Rayleigh  curve  were  calculated. 

After  the  curve  fitting  was  completed,  the  parameters  K, 

a,  and  t  for  the  life  cycle  curves  and  the  corresponding 
d 

aaintenance  curves  were  compared  to  examine  possible  common 


relationships.  Curve  magnitudes  at  t  for  the  life  cycle 

ip 

and  Y*  (t  )  for  the  maintenance  curve  were  also  compared 
sax  d 

in  terms  of  the  general  relationships  proposed  by  Green  and 
Selby* 

C.  ANALYSIS  RESULTS 

An  excellent  fit  was  obtained  for  the  life  cycle  curves 
for  all  five  individual  projects  in  relation  to  the  Rayleigh 
model.  Proa  Table  VII,  correlation  coefficients  ranged  froa 
r2  *  0.776,  for  the  NASA  project,  to  r2  *  0.966,  for  Project 
A.  The  curve  fit  for  the  combined  Bankers  Trust  projects 
obtained  an  r2  *  0.869.  However,  aaintenance  curves,  in 
general,  did  not  fit  the  Rayleigh  aodel  well,  with  correla¬ 
tion  coefficients  ranging  froa  r2  *  0.118  for  NASA  data  to 
r2  ■  0.762  for  Project  B.  Projects  B  and  D  maintenance 

curves  best  fit  the  Rayleigh  aodel  with  r2  *  0.762  and  0.747 
respectively.  These  findings  indicate  that  the  aaintenance 
efforts  are  somewhat  erratic,  as  alluded  to  in  the  GAO 
study,  and,  therefore,  do  not  fit  a  specific  curve  well. 
Hhen  maintenance  is  not  managed  as  a  discrete  function, 
aanloading  peaks  and  drops  in  an  inconsistent  manner.  This 
normally  results  as  managers  respond,  on  a  crisis  basis,  to 
provide  maintenance  activity  only  when  trouble  arises. 

In  the  NASA  data,  however,  though  the  overall  mainte¬ 
nance  data  does  not  fit  the  Rayleigh  curve  well,  visual 
inspection  cf  the  curve  reveals  what  appear  to  be  a  series 
of  small  Rayleigh- like  curves,  the  combination  of  which 
exhibit  an  overall  rise  of  maintenance  manloading  across  the 
available  data,  as  can  be  3een  in  Figure  (5.1). 

This  trend  fits  well  with  the  project  characteristics  which 
show  that  the  size  of  the  project  has  grown  from  4000  SLOC 
to  about  73,000  SLOC  during  its  life  cycle  to  date.  It 


tUf*  PROJECT  MYLEltH  CURVES 


stands  to  reason  that  the  "mini-development  cycles"  for 
those  modi f icat ions/enhance ments  which  created  the  increase 
in  systea  size  would,  themselves,  exhibit  a  Rayleigh 
pattern,  but  the  aggregate  maintenance  phase  would  not 
necessarily  follow  the  same  pattern.  The  aggregate  curves 
are  included  in  Appendix  C. 

Comparison  of  parameters  gave  varying  results,  as  can  be 

seen  in  Table  VII.  Ratios  of  life  cycle  K's  to  maintenance 

K*s  ranged  from  0.148  to  1.24  and  ratios  of  life  cycle  t^*s 

and  maintenance  t  * s  ranged  from  0.6  25  to  2.82.  This  seems 

d 

to  indicate  that  no  general  relationship  can  be  derived 

which  relates  K*s  and  t  's  for  the  maintenance  phase  versus 

d 

the  life  cycle  with  respect  to  individual  projects.  However, 
as  more  data  is  accumulated  and  research  efforts  continue, 
those  relationships  might  be  found  to  exist  for  various 
aggregate  projects. 

ahen  Y *  of  the  individual  fitted  life  cycle  curves 

tip 

was  compared  to  Y*  of  the  individual  fitted  maintenance 

t  a 

curves,  similar  results  to  those  obtained  for  K  and  t 

a 

comparisons  were  observed.  The  ratios  covered  a  wide  spec¬ 
trum.  However,  when  the  comparison  was  made  for  the 

combined  3ankers  Trust  projects  curves,  the  results  were 
strikingly  similar  to  those  of  the  NASA  project  and  the 
USACSC  data.  tJSACSC  data  indicated,  as  shown  in  Chapter  IV, 

that,  on  the  average,  Y*  *  75  percent  of  y*  .  Comparison 

tm  tip 

of  actual  maximum  aanloading  for  the  combined  Bankers  Trust 

project  data  to  the  inflection  point  on  the  fitted  life 

cycle  curve  gave  Y’  *  69.6  percent  of  Y*  .  Though  or.lv 

tm  tip 

one  project,  instead  of  an  aggregate,  the  NASA  data  also 

shoved  a  general  behavior  of  Y1  =  69  percent  of  Y* 

tm  t  ip 

For  the  NASA  project,  this  interpretation  may  be 
questionable,  3ince  some  data  points  lay  above  the  69 
percent  of  Y'  .  level.  In  fact,  one  point  lay  above  Y*  .  . 


TABLE  VII 

Compilation  of  Analysis  Results 

Life  Cycle  Parameters 


NAME 

a  t 

d 

K 

T* 

max 

y* 

tip 

tip 

NASA  Project 

.003969  11 

28.410 

1.54 

0.9982 

19.44 

Project  A 

.007143  8 

183.374 

13.27 

8.8586 

14.49 

Project  B 

.014294  6 

137.276 

14.08 

8.8422 

10.25 

Project  C 

.0076  05  8 

186.913 

13.98 

9.0296 

14.04 

Project  D 

.024288  5 

81.383 

10.77 

6.2905 

7.86 

Co mb' n  A-D 
(norm.  td*1) 

.598560  1 

19.435 

12.89 

8.2190 

1.58 

Ha inte nance 

Phase  Parameters 

NAME 

a 

t 

e 

K 

Y* 

max 

NASA  Project 

.000525 

31 

35.234 

0.693 

Project  A 

.0  224  20 

5 

27. 165 

3.477 

Project  B 

.019000 

5 

47.204 

5.579 

Project  c 

.006000 

7 

53.  127 

4.000 

Project  D 

.0  05900 

9 

56.699 

3.740 

Comb'n  A-D 
(norm.  td»1) 

.311000 

1.  26 

8.480 

4.080 

Miscellaneous  Parameters 

NAME 

td(LC) 

MLC) 

I*  tm 

T' tip 

Main 

Corr. 

Life 

Cycle 

Corr. 

NASA  Project 

2.820 

1.24 

.694 

.118 

.776 

Project  A 

0.625 

.  148 

.  392 

.511 

.966 

Project  B 

0.833 

.  343 

.631 

.762 

.872 

Project  c 

0.875 

.  284 

.  443 

.482 

.939 

Project  D 

1.800 

.696 

.595 

.747 

.893 

Comb’n  A-D 
(norm.  td*1) 

1.260 

.436 

.496 

.388 

.869 

However,  if  one  accepts  the  theory  that  the  RASA  project  is 

characterized  during  the  eaintenance  phase  by  a  series  of 

"mini-development  phases”,  then  the  points  above  the  69 

percent  level  can  be  interpreted  as  Banning  levels  intrinsic 

to  the  development  effort  and  not  characteristic  of  a 

general  Maintenance  progran.  Then  the  aggregated  naxioun 

maintenance  level  lies  at  6  9  percent  of  . 

tip 

D.  CHAPTER  FIVE  SO MM ARY 

The  data  were  analyzed  using  non-linear  curve  fitting 
techniques  to  provide  life  cycle  versus  maintenace  phase 
relationship  comparisons.  The  results  seem  to  exhibit  inde¬ 
pendence  of  behavior  with  respect  to  values  of  K  and  t^. 
However,  a  general  trend,  within  the  limited  scope  of  data 
available,  was  found  which  appears  to  point  to  a  possible 
relationship  between  maintenance  manloading  levels  and  the 
magnitude  of  the  inflection  point  on  the  life  cycle  curve. 


The  history  of  the  software  industry  has  been  marked  by 
cost  overruns,  late  deliveries,  poor  reliability  and  mainte¬ 
nance,  and  user  dissatisfaction.  While  these  problems  are 
not  unique  to  computing,  the  record  seems  to  indicate  that 
software  developers  as  a  group  are  less  successful  in 
meeting  quality,  cost,  and  schedule  objectives  than  their 
hardware  counterparts. (34]  tiith  this  in  mind,  a  number  of 
models  have  been  developed,  as  discussed  in  Chapter  II,  to 
provide  management  the  necessary  tools  to  more  accurately 
predict  the  actual  costs  and  time  frames  for  their  software 
projects.  This  thesis  attempted  to  expand  the  work  done  by 
Green  and  Selby  on  Putnam's  model,  with  special  emphasis  on 
the  maintenance  phase  of  the  software  life  cycle.  This 
included  a  detailed  comparison  of  the  peak  manloading  for 
the  maintenance  phase  with  the  inflection  point  on  the  total 
life  cycle  Hayleigh  curve. 

b.  conclusions 

The  software  project  manpower  macro-estimating  model,  as 
presented  by  Green  and  Selby,  is  not  a  usable  model  for  the 
project  manager.  Is  was  demonstrated  in  Chapter  IV,  and 
again  in  the  data  analysis  in  Chapter  V,  the  maximum  point 
on  the  maintenance  curve  is  net  necessarily  equal  to  the 
magnitude  at  the  inflection  point  of  the  life  cycle  curve, 
though,  theoretically,  it  is  possible  for  the  two  points  to 
be  equal.  It  was  also  found  that  the  absolute  point  in  time 
of  the  maximum  maintenance  manloading  and  the  inflection 


point  «ay  coincide,  bat,  usually,  will  not.  However,  these 
findings  do  not  invalidate  the  basic  ideas  froa  which  the 
Green/Selby  nodel  were  developed.  Those  basic  ideas  were 
that  a  relationship  say  exist  whereby  maintenance  nanpower 
could  be  projected  by  conparison  of  the  Maintenance  phase 
and  life  cycle  Hayleigh  curves,  or  derivations  thereof.  It 
was  shown  that,  within  the  scope  of  the  liaited  available 
data,  only  two  of  the  five  projects  analyzed  were  character¬ 
ized  by  naintenance  phases  which  closely  fit  the  Rayleigh 
nodel.  However,  it  was  demonstrated  that,  for  coabined 
project  data,  within  project  type,  and  within  a  specific 
organization,  a  relationship  does  appear  to  exist  between 
the  aaxiaua  naintenance  manpower  utilization  level  and  the 
inflection  point  of  the  life  cycle  curve,  whether  the  main¬ 
tenance  phase  fits  the  Hayleigh  model  or  not. 

In  both  the  OSACSC  and  combined  Bankers  Trust  Co.  data 
analyses,  and  vith  interpretive  license  in  the  NASA  data 
analysis,  maximum  maintenance  levels  were  within  65  percent 
to  75  percent  of  the  level  of  .  There  is  not  enough 

evidence  here  to  show  that  there  exists  a  general  rule  that 
maximum  maintenance  will  be  about  70  percent  of  the  magni¬ 
tude  at  the  life  cycle  curve  inflection  point,  but  the 
implications  for  project  managers  within  individual  organi¬ 
zations  are  encouraging.  The  results  of  the  data  analysis 
appear  to  indicate  that,  for  project  type,  within  an  indi¬ 
vidual  organization,  analysis  of  historical  data  and  compar¬ 
ison  of  maintenance  levels  to  life  cycle  curve  inflection 
points  will  provide  a  general  baseline  maximum  maintenance 
support  level  vhich  the  manager  can  use  in  out year  mainte¬ 
nance  manning  projections  for  future  projects.  For  example, 
if  historical  data  for  accounting  type  projects  in  organiza¬ 
tion  X  shows  that  maximum  maintenance  manning  is  65  percent 
of  the  magnitude  at  the  life  cycle  curve  inflection  point. 


then  the  manager  can  apply  that  percentage  to  the  projected 
life  cycle  curve  calculations  for  fatuze  projects  to  obtain 
a  aaictenance  support  projection  at  the  inception  of  the 
project.  Is  the  life  cycle  curve  is  refined  during  the 
development  phase,  the  maintenance  level  projections  can  be 
successively  refined.  This  would  provide  the  ADP  manager 
with  a  valuable  tool  in  an  environment  presently  character¬ 
ized  by  a  general  lack  of  planning  and  management  direction, 
in  the  area  of  software  maintenance. 

The  results  of  the  data  analysis  further  indicate,  by 
their  lack  of  strong  correlation,  that  there  are  other 
factors  which  may  have  a  strong  effect  on  the  level  of  main¬ 
tenance  required  for  any  software  system.  This  finding  is 
not  entirely  surprising,  as  the  authors  of  this  thesis, 
after  extensive  readings  in  the  literature,  did  not  have 
much  confidence  in  the  possibility  of  discovering  a  single, 
general,  simple  decision  rule  for  software  maintenance 
manning.  Bather,  the  research  completed  here  is  only  a  tiny 
bite  taken  from  the  mountain  of  research  which  needs  to  be 
done.  The  possible  set  of  constraints  and  combinations 
thereof  which  affect  the  software  process  is  astounding.  A 
few  were  highlighted  by  this  research  effort.  It  was  found 

that  there  was  no  firm  relationship  between  K's  and  t  's  of 

d 

the  corresponding  life  cycle  and  maintenance  phase  curves. 
It  can  be  hypothesized  that  differences  in  K's  (total  life 
cycle  manning)  are  attributed  to  such  factors  as  project 
size,  complexity,  and  project  type.  It  follows  that  larger 
projects  will  require  higher  overall  manning  levels  than 
smaller  sized  projects.  The  relationships  of  maintenance  t 

1 

versus  life  cycle  t  are  affected,  in  large  part,  by 

d 

complexity  and  size  of  the  project.  Differing  system 
complexities  say  place  heavier  burdens  on  different  phases 
of  the  development  processes,  and,  thus,  cause  t  (time  of 


aaxiaua  Banning)  to  occur  at  different  tiaes  for  different 

projects.  There  aay  be,  and  the  authors  of  this  thesis  feel 

that  there  vill  be,  no  definable  relationship  between  the 

point  of  naxiaun  Banning  for  the  maintenance  phase  and  the 

corresponding  td  for  the  life  cycle.  Since  only  two  of  the 

five  projects  analyzed  actually  fit  the  Bayleigh  model  for 

the  maintenance  phase,  it  would  appear  that  for  some 

projects,  a  definable  t  would  be  forever  elusive.  Only  in 

d 

those  projects  where  some  type  of  "mini-development"  effort 

is  completed  in  the  process  of  providing  enhancements  or 

major  modifications  will  a  good  fit  to  the  Bayleigh  model  be 

realized,  accompanied  by  a  definable  maintenance  t  versus 

d 

life  cycle  t  relationship  for  that  project, 
d 

&  constraint  of  even  greater  importance  is  the  use  of 
varying  software  development  techniques  and  methodologies. 
It  has  been  speculated  that  the  majority  of  research  to  date 
has  been  conducted  with  data  collected  from  projects  which 
were  characterized  by  design  and  coding  efforts  which  did 
not  include  structured,  modular-design  techniques,  informa¬ 
tion-hiding  modules,  and  other  software  development  concepts 
and  tools.  These  projects  have  shown  a  very  close  relation¬ 
ship  with  the  Bayleigh  model.  k  tremendous  impact  on  the 
entire  arena  may  be  seen  with  the  increased  use  of  the  above 
listed  design  techniques.  How  these  techniques  vill  affect 
the  software  equation  and,  in  particular,  software  mainte¬ 
nance,  is  yet  to  be  seen. 

The  rise  in  maintenance  activity  for  the  H&S&  project, 
as  new  developments  apparently  added  modules  and  source 
lines  of  code  to  the  system,  seems  to  support  the  results 
obtained  by  Lehaan  and  Belady,  as  described  in  Chapter  II, 
that,  as  enhancements  are  added  to  the  original  project,  the 
maintenance  level  required  to  support  the  project  also 
rises.  This  could  be  attributed  to  the  fact  that  the 


addition  of  enhancements  adds  complexity  to  the  system 
which,  in  turn,  causes  a  resultant  increase  in  the  mainte¬ 
nance  level  required.  As  was  discussed  earlier,  and  as  is 
seen  in  the  NASA  project  data,  if  enhanceaents  continue,  the 
aaintenance  manning  rises  above  the  aagnitude  of  the  inflec¬ 
tion  point  on  the  life  cycle  curve.  This  could  also  indi¬ 
cate  that  the  point  in  time  at  which  the  project  should  be 
totally  rewritten  and  restructured  as  a  new  project  has  been 
reached,  and  any  further  development-like  effort  on  the 
systea  should  constitute  the  inception  of  a  new  project. 

C.  RECOMMENDATIONS 

One  of  the  most  difficult  probleas  encountered  in  the 
preparation  of  this  thesis  was  locating  organizations  which 
had  compiled  and/or  retained  historical  data  froa  their 
software  development  and  aaintenance  efforts.  Sone  of  the 
organizations  contacted  had  aaintained  some  fora  of  histor¬ 
ical  data,  but  they  had  not  broken  their  information  down 
into  a  format  which  could  be  used  to  obtain  information 
about  the  separate  phases  of  the  software  life  cycle. 
Therefore,  if  any  meaningful  research  is  to  be  conducted  in 
the  future  in  this  area,  organizations  which  are  responsible 
for  producing  or  aaintaining  software  products  need  to  start 
accounting  properly  for  the  various  costs  associated  with 
this  process.  Proper  accounting  includes,  not  only  tracking 
the  number  of  source  lines  of  code  produced  for  the  project, 
but  total  aan-hours  expended  in  each  phase,  the  actual  time 
frame  for  each  phase,  and  the  applicable  coaplexity  factors. 
The  collection  of  this  data,  however,  must  be  an  ongoing 
process,  just  as  is  proper  documentation  of  software,  and  it 
should  become  a  part  of  this  documentation.  By  making  the 
collection  process  an  ongoing  process,  the  data  is  always 
current,  and  less  subject  to  error.  Por,  like  any  other 


fora  of  documentation,  if  postponed  until  the  end  of  the 
project,  it  is  subject  to  a  host  of  errors,  oaissions,  and 
inaccuracies.  However,  even  if  the  collection  process  is 
done  with  total  perfection,  it  means  nothing  unless  the  data 
is  recorded  in  such  a  manner  that  it  can  be  retrieved  and 
understood  easily.  It  is  therefore  recoaaended  that  this 
data  be  stored  in  an  automated  data  file  so  that  it  can  be 
accessed  quickly  and  analyzed  with  greater  ease  and  effi¬ 
ciency  than  with  a  manual  system.  With  the  cost  of  software 
rising  at  an  ever  increasing  rate,  the  benefits  of  this 
information  to  the  organization,  seem  obvious.  Not  only 
should  it  be  better  able  to  predict  future  software  manning 
requirements,  but  also,  it  should  be  able  to  identify  and 
correct  other  inefficiencies  within  the  development  and 
maintenance  processes. 

As  noted  by  GAO,  and  as  indicated  by  the  NASA  data,  a 
generally  accepted  but  uniform  definition  of  software  main¬ 
tenance  is  not  now  in  existence  in  the  majority  of  organiza¬ 
tions.  In  addition,  management  is  not  presently  requiring 
that  software  maintenace  be  managed  as  a  discrete  function. 
This  leads  to  many  problems  for  management  at  various  levels 
of  the  organization.  As  such,  it  is  recommended  that  the 
definition  proposed  by  GAO  be  adopted  as  the  uniform  defini¬ 
tion  of  software  maintenance.  It  also  is  recoaaended  that 
software  maintenance  be  accomplished  as  a  discrete  function 
within  the  organization.  The  adoption  of  the  GAO  definition 
will  leave  a  grey  area  where  enhancements  to  the  old  project 
stop  and  a  new  project  begins.  However,  if  management 
formulates  a  project  maintenance  strategy  which  includes  the 
development  of  a  maintenance  support  level,  whether  it  is 
based  on  a  percentage  of  the  magnitude  at  the  inflection 
point  on  the  life  cycle  curve,  or  on  some  other  management- 
defined  function,  a  point  will  exist  above  which  management 


should  decide  to  terminate  enhancements  to  that  project  and 
start  a  nev  project.  This  project  would  be  developed  as  a 
follow-on  to  the  old  system.  The  old  project  should  be 
terminated  or  continued  with  a  minimum  maintenance  support 
level  to  effect  necessary  repairs  until  the  new  system  comes 
online. 

although  there  appears  to  be  a  strong  correlation 

between  peak  maintenance  manloading  and  a  fixed  percentage 

of  the  manloading  at  the  inflection  point  of  the  total  life 

cycle  Hayleigh  curve,  further  work  needs  to  be  done  to 

determine  if  this  relationship  holds  true  throughout  the 

software  industry.  This  work  should  include  comparisons 

across  all  types  of  software  and  comparisons  within  each 

class  to  determine  if  there  is  a  value  that  management  could 

use  as  a  planning  tool  for  the  type  of  software  they  are 

producing.  Follow-on  research  to  this  thesis  would  be  most 

beneficial  if  completed  in  the  following  manner.  &  larger 

base  of  life  cycle/a ain ten ance  data  must  be  collected  to 

provide  a  better  picture  of  the  relationships  concerned  and 

to  obtain  a  higher  percentage  of  validity  in  the  findings. 

Projects  need  to  be  analyzed  individually,  grouped  by 

project  size,  grouped  by  type  of  system  involved,  grouped  by 

complexity  factors  (if  known),  and  grouped  within  specific 

organizations  as  well  as  a  total  combination  of  the 

collected  population.  Research  should  be  done  to  examine 

potential  relationships  of  K*s,  t  *s,  and  T»  ,  versus  T* 

r  d  tip  tm 

for  the  corresponding  life  cycle  and  maintenance  curves.  A 

particularly  important  area  of  research  will  be  the  effect 
of  new  software  development  techniques  on  the  software  equa¬ 
tion.  Any  data  collected  on  projects  which  were  developed  in 
this  manner  should  be  segregated  and  analyzed  separately. 
The  potential  for  research  in  this  area  is  unlimited  in 
scope  and  in  promise. 
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AM1X21S  Ql  SfimiU  £0£&s  bx  thibodsau 

A.  INTRODUCTION 

Robert  Thibodeau,  while  working  for  General  Research 
Corporaton,  was  contracted  by  the  Air  Force  to  conduct  a 
study  of  the  various  nodels  currently  avalilable  for  soft¬ 
ware  cost  estimation.  This  appendix  consists  of  excerpts 
from  his  review. 

B.  AEROSPACE  NODE! 

Description  of  the  Model 

The  aodel  was  developed  using  regression  techniques 
applied  to  data  from  software  development  projects  charac¬ 
terized  by  one-of-a  kind  computers,  limited  support  soft¬ 
ware,  software,  special  languages  and  severe  memory  size  and 
speed  requirements.  The  data  were  stratified  into  two 
groups.  One  group  contained  13  projects  for  the  development 
of  real  time  software  identified  as  primarily  large-scale 
airborne  and  space  applications.  The  second  group  consisted 
of  7  operational  support  programs  presumably  without  the 
size  and  speed  requirements  of  the  first  group. 

The  model  description  is  not  clear  concerning  the  exact 
composition  of  the  estimate  of  effort  required  to  develop 
the  software.  Only  the  total  effort  is  extiaated.  The 
estimate  is  made  using  a  relationship  of  the  form: 

,  b 

3H  *  a  (Instruction) 

where  the  constants,  a  and  b,  are  determined  by  regression 
analysis. 


r* 


The  estimating  relationships  are: 

l&l  lias  saiiaass 


MM  *  0.057  (I) 
Support  Software 


0.94 


MM  *  2.012  (I) 


0.404 


where: 

MM  *  total  development  effort,  manmonths 
I  *  nuaber  of  instructions  (independent  of 
language) .... 

C.  DOD  HXCBO  ESTIMATING  PROCEDURE 
Description  o£  the  aaiSi 

The  primary  estiaating  relationship  coaprising  the  DoD 
Micro  Procedure  can  be  described  as  the  ratio  of  a  factor 
representing  the  software  to  be  developed  or  changed  and  a 
productivity  measure. 

The  model  form  suggests  that  effort  increases  directly 
with  the  nuaber  of  input  and  output  configurations  operating 
on  the  system  being  built.  Effort  also  increases  with  the 
number  of  routines  being  created  or  modified  weighted  by 
their  difficulty.  The  total  effort  is  scaled  according  to 
the  amount  of  work  that  must  be  done  in  entirety  as  opposed 
to  modification  of  an  existing  system. 

The  nuaber  of  days  needed  to  deliver  the  product  (effec¬ 
tively  the  days  of  effort  per  unit  of  product)  depends  on 
the  general  experience  and  accomplishment  of  the  development 
group  (measured  by  their  job  classifications)  weighted  by 
their  knowledge  of  the  problem  to  be  solved  relative  to  the 
knowledge  required.  One  other  factor  that  directly  affects 
the  productivity  is  the  ease  of  access  to  the  computer 
(measured  by  turnaround  time). 
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the  basic  fora  of  the  estimating  relation  for  software 
development  tine  is: 

Net  Development  Time  =  (Product)  /  (Productivity) 

Where: 

Product  is  a  measure  describing  the  effort  to  be  per** 
formed. 

Productivity  is  the  rate  of  creating  the  product  from 
the  application  of  personnel  time. 

Product  *  (Number  of  Formats  ♦  Weighted  Number  of 
Functions)  x  (Effort  Relative  to  a  New 
Development) 

The  terms  in  parentheses  along  with  the  following  terms 
are  defined  in  the  discussion  of  model  inputs  below: 

(Productivity)1*  (work  Days  per  Unit  of  Product  for  a 

Staff  with  Average  Experience) 
x  (Job  Knowledge  Required) 

x  (Job  Knowledge  Available) 

x  (Access) 

The  result  is  the  total  hours  required  for  code  develop¬ 
ment.  Presumably  this  means  detailed  design,  coding,  and 
unit  testing. 

Gross  Development  Time  *  (Net  Development  Time) 

x  (Other  System  Factor) 
x  (Non- Project  Factor  ♦  Lost 
Time  Factor) 

A  value  of  1.8  is  recoroended  for  the  other  system 
factor.  This  factor  represents  the  effort  needed  to  convert 

the  code  development  time  to  total  development  time.  This 

value  is  representative  of  an  observed  range  from  1.2  to 
2.1.  Total  development  includes  analysis,  design,  coding, 
testing  and  documentation.  It  is  the  sum  of  the  project 
direct  charges.  Whether  this  includes  support  hours  for 


clerical  and  other  functions  is  not  clear.  but  an;  given 
organization  could  include  these  by  aodifying  the  1.8 
factor. 


The  net  development  tiae  accounts  for  the  tiae  lost  froa 
noraal  scheduled  working  hours  for  leave,  sickness,  holi¬ 
days,  and  non-project  assignments.  These  add  25  percent  to 
the  total  development  tiae.  There  is  also  a  10  percent 
efficiency  factor  (coffee  breaks,  tiae  cards,  code  rework, 
etc.)  .  The  code  rework  should  probably  be  handled  else¬ 
where.  It  is  probably  included  where  it  is  to  aake  the  10 
percent  palatable.  It  should  be  included  in  the  gross  size 
adjustaent  and  the  1.8  factor. 

The  effect  of  these  adjustments  is  to  estimate  the 
number  of  personnel  who  must  be  assigned  to  the  project  to 
ensure  delivery  of  the  total  development  hours.  These 
factors  are  orgainizational  specific. 

Although  the  resource  estimating  procedure  includes 
weighting  factors  for  the  input  and  output  formats  by  type 
of  device  (see  subsequent  discussion) ,  the  factors  have  a 
value  of  one  in  each  case.  Therefore,  the  model  describes  a 
linear  relationship  between  the  total  number  of  file  formats 
and  the  effort  required  to  implement  them.  It  may  be  that 
future  versions  of  the  model  will  weight  the  types  of  file 
device  differently.  Then  the  effort  required  to  implement  a 
report  format  aay  be  different  froa  the  effort  required  for 
a  card  format. 

Program  complexity,  which  is  the  second  term  in  the 
product  measure,  is  the  weighted  sub  of  the  functions  to  be 
implemented.  The  weights  depend  on  the  function  and  its 
assumed  level  of  complexity.  The  weights  range  from  1  for  a 
simple  operating  system  control  language  change  to  12  for  a 
very  complex  edit-validation  function. 
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The  value  3  is  the  most  common  aeong  the  24  possible 
function-complexity  assignments.  If  the  function  types  are 
equally  represented  in  prograas,  the  average  value  is  4. 

The  prograaaer/analyst  experience  factor  is  an  indica¬ 
tion  of  the  effect  of  experience  on  productivity.  Values 
range  froa  .75  to  2.75  corresponding  to  a  lead  analyst  to 
prograaaer  and  interns  respectively.  since  experience  is 
not  evenly  distributed  aver  a  group  of  prograaaers  and 
analysts,  the  following  groups  was  hypothesized  in  order  to 
obtain  an  average  or  representative  value  for  the  experience 


factor. 

Experience 

Nuaber 
in  Group 

Factor 

Weighted 

Sum 

lead 

1 

.75 

.75 

Senior 

2 

1.25 

2.50 

Journeyman 

4 

1.75 

7.00 

Nominal 

8 

2.25 

18.00 

Intern 

5 

2.75 

13.75 

Average  Value  * 

20 

42  /  20  * 

2.1 

42.00 

No  definitions  are  provided  for  the  10  job  classifica¬ 
tions.  The  job  knowledge  and  turn-around  tine  factors  are 
self-explanatory. 

The  Systen  Factor  adjusts  the  product  development  effort 
to  account  for  work  alrea  dy  done.  The  product  measure 
resulting  froa  the  format  count  and  the  program  complexity 
value  is  the  sane  whether  the  systei  is  being  developed  in 
its  entirety  or  it  is  a  modification  to  an  existing  system. 
The  system  factor  has  the  effect  of  modifying  the  product 
value  to  account  for  less  than  total  development. 

Seven  levels  of  change  are  described  by  the  System 
Factor.  The  values  range  froa  2  for  a  new  development  to  9 


for  at  operating  systems  control  language  change. 


For  a  new  systea  developaent  the  2  xn  the  priaary  esti¬ 
mating  equation  is  divided  by  a  Systea  Pactor  value  of  2  and 
the  product  measure  is  unchanged.  Consequently,  the  Systea 
Factor  values  describing  lesser  aaounts  of  new  developaent 
have  larger  values  and  are  portions  of  2.  The  effect  of  the 
Systea  Factor  on  the  product  measure  is  summarized  as 
follows: 


Type  of  Effort 


Systea  Factor 


Effort  Relative  to 
a  New  Development 


New  Developaent  2  1.00 

Major  Change  3  .67 

Major  Modification  4  .50 

Minor  Modification  5  .40 

Maintenance  6  .33 

Minor  Technical  Change  7  .29 

Operating  Systems 

Control  Language  Change  8  .25 

In  order  to  get  a  feel  for  the  relative  magnitudes  of 
the  coaponents  of  the  Micro  Estimating  Procedure,  consider 
the  following  example. 

Huaber  of  I/O  formats  *  10 
Humber  of  functions  a  20 

Average  complexity  factor  *  4. 

Hew  Developaent 

Product  =  (Huaber  of  Formats  ♦  Weighted  Huaber  of 
Functions)  x  (Effort  Related  to  a  Hew 
Developaent ) 

Product  *  (10  ♦  4  x  20)  x  2  /  2  *  90 

Experience  »  2.  (See  above  for  computation) 

Job  knowledge  required  *  1.0 
Job  knowledge  available  »  1.0 
Access  *  *  1.0 

(Productivity)  *  (Work  Days  per  Unit  of  Product  for  a 

Staff  with  Average  Experience) 


x  (Job  Knowledge  Required) 
x  (Job  Knowledge  Available) 
x  (Access) 

«  2.0  x  1.0  x  1.0  x  1.0  *  2.0 

-1 

Net  Development  Time  *  (Product)  x  (Productivity) 

■  90  x  2.0  *  180  Man-Days 

If  the  effort  was  a  major  modification  (System  Factor  * 
4),  the  Product  value  becomes: 

product  *  (10  ♦  4  x  20)  x  2/4  »  45 
and 

Net  Development  Time  *  45  x  2.0  *  93  Man-Days 

If  the  Job  Knowledge  Required  is  "Detailed"  (Factor  * 

1.5)  and  the  Job  Knowledge  Available  is  "Limited"  (Factor  * 

1.5) ,  and  the  productivity  becomes: 

-1 

(Productivity)  *  2.0  x  1.5x  1.5  x  1.0  *  4.5 
then  for  the  major  modification: 

Net  Development  Effort  *  45  x  4.5  *  20 2.5  Man-Days 

Si&p.gSa 

The  primary  output  (i.e.,  the  output  that  is  sensitive 
or  controlled  by  project  variables  as  opposed  to  the  subse¬ 
quent  step  which  is  a  fixed  allocation)  is:  Gross 
Development  Time  (man-days).  Gross  Development  Time 

includes: 

•  Nonproject  time  (individual  assigned  to  project  but  busy 
with  nonproject  tasks,  e.g. ,  training,  nonproduct  admin¬ 
istrative  duties,  etc.,  and  vacation  and  holidays) 

•  Wasted  or  lost  time 

therefore.  Gross  Development  Time  describes  the  staffing 
level  that  will  result  in  a  needed  amount  of  development 
time.  The  latter  is  predicted  by  program  and  project 
cha  r  a  ct  er  i  st  i  cs . 
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Th«  secondary  outputs  (i.e. ,  those  derived  by  applying 
fixed  values  to  the  prisary  output  are: 

•  Effort  by  project  phase 

•  Total  development  cost 
The  project  phases  are: 

•  Review  and  analysis 

•  Design 

•  Prograising 

•  Testing 

•  Documentation 

Gross  Development  Tine  includes: 

Analysis  of  present  methods 
Design  of  the  nev/changed  system 
Develop  the  system*  s  support 
Program  design 
Program  development 
Program  testing 
System  testing 
Installation  and  conversion 
Staff  training 
Project  officer 
System  manager 
Technical  managers 
Support  personnel 
Documentation 
meats 

pyodgct  Related  Inputs .  The  software  is  described  by 
the  numbers  of  types  of  items  it  processes  and  the  numbers 
of  functions  it  includes.  The  functions  are  described 
according  to  type  and  complexity.  The  result  is  two  product 
descriptors:  one  measures  the  size  of  the  input/output 

processing  to  be  executed  by  the  system;  the  other  is  a 
measure  of  the  number  and  difficulty  of  the  functions  to  be 
performed. 
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Input  Pile  For eats.  The  nueber  of  different  formats  to 
be  read  bp  the  system  are  counted  and  added  together.  The 
aodel  asks  for  nuabers  of  cud,  tape,  disk,  and  screen 
foraats  separately,  but  since  the  weighting  factor  is  always 
one,  there  is  no  distinction  Bade  aaong  then  regarding  the 
effort  involved  to  iaplenent  then. 

Output  Pile  Foraats.  The  foraats  output  by  the  3ysten 
are  totaled.  The  sane  entries  as  for  the  inputs  are 

requested  plus  the  nuaber  of  report  foraats.  &s  in  the  case 
of  the  inputs,  the  weighting  factor  for  the  different  types 
of  output  is  always  one,  so  there  is  no  reason  to 
dif  f erentiate. 

Procraa  Complexity.  The  total  program  complexity 
measure  is  computed  by  a  weighted  sum  of  the  nuaber  of 
processing  functions  of  given  types.  Each  function  is  char¬ 
acterized  as  simple,  coaplex,  or  very  complex.  The 

processing  functions  are: 

•  Edit  Validation 

•  Table  Look- Op  (Internal  or  External) 

•  Calculations 

•  Sort/Herge  Process 

•  Internal  Data  Hanipulation 

•  Pile  Search 

•  Utilities  or  Subroutines 

•  Operating  Systems  Control  Language 

Job  Knowledge  Required.  The  amount  of  knowledge 
required  to  iapleaent  or  change  a  system  has  a  direct  effect 
on  the  nuaber  of  hours  required  to  accomplish  the  project. 
A  system  that  requires  very  detailed  knowledge  will  require 
more  effort  than  one  that  can  be  accomplished  with  limited 
knowledge.  This  parameter  is  paired  with  the  job  knowledge 
available  factor  described  below  to  describe  the  relative 
influence  on  productivity.  Three  job  knowledge  levels  are 
used:  Limited,  General.  Detailed. 


System  Pact 05.  The  effort  required  to  complete  a  system 
development  or  change  project  of  given  complexity  depends  on 
the  state  of  the  system.  That  is,  the  work  required  to 
develop  a  system  with  three  file  formats,  all  other  factors 
being  equal.  The  System  Pactor  describes  the  level  of 
effort  being  undertaken.  Seven  levels  are  described: 

•  System  development 

•  Hajor  changes 

•  Major  modification 

•  Minor  modification 

•  Maintenance 

•  Minor  technical  change 

•  Operating  systems  control  language 
Resource  Related  Incuts 

£iaaaaitlZiaal ial  Experience  available.  The  available 
experience  measure  is  an  effective  productivity  indicator. 
It  quantifies  the  rate  at  which  the  product  can  be  produced 
in  terns  of  the  job  classification  of  the  staff  available 
for  assignment  to  the  system  development.  Two  data 
processing  personnel  classifications:  Analyst  and 

Programmer,  are  tabulated  according  to  five  levels  of  expe¬ 
rience:  Lead,  Senior,  Journeyman,  Nominal,  and  intern. 
Weights  are  associated  with  the  difference  experience 
levels.  The  result  is  a  weighted  average  productivity 
factor. 

Jqfr  Knowledge  Ayaila ble .  This  factor  has  the  effect  of 
describing  the  change  in  productivity  associated  with  the 
level  of  knowledge  about  the  work  to  be  performed  that 
exists  among  the  persons  available  for  assignment.  It  works 
together  with  the  Job  Knowledge  Required  factor  described 
above  to  quantify  the  effect  of  the  knowledge  of  the  system 
required  compared  to  that  available  on  the  time  required  to 
complete  the  work.  In  general,  the  effect  of  the  combined 


factors  is  to  increase  the  development  manhours  if  the  need 
exceeds  the  available  and  decrease  the  hours  if  the  avail¬ 
able  exceeds  the  need.  Three  levels  of  job  knowledge  avail¬ 
ability  are  specified:  Limited,  General,  and  Detailed. 

Prooraa  Turn-Around  liig.  The  effect  of  computer  access 
on  productivity  is  described  by  four  levels  of  average 
turn-around  time: 

•  Interactive  terminal 

•  Hore  * han  one  run  per  day 

•  One  run  per  day 

•  Less  than  one  run  per  day. 

D.  DOTY  ASSOCIATES,  INC. 

Description  of  the  Model 

The  model  is  actually  a  set  of  15  estimating  relation¬ 
ships.  Each  one  to  be  used  for  a  given  type  of  software  and 
software  life  cycle  phase.  Equations  have  been  derived 
empirically  using  regression  analysis  for  the  following 
types  of  software: 

•  Command  and  Control 

•  Scientific 

•  Business 

•  Utility 

The  development  effort  for  software  representing  each  of 
the  application  types  may  be  estimated  usipg  one  of  three 
different  relationships.  An  additional  three  are  given  that 
are  applicable  to  all  types  of  software.  These  equations 
are  to  be  used  "when  the  application  cannot  be  categorized 
or  is  different  than  the  categories  noted**.  The  procedure 
specifies  that  when  a  software  system  is  made  up  of  subsys¬ 
tems  that  are  different  types,  the  total  size  should  be 
divided  into  the  four  categories  and  the  appropriate  esti¬ 
mating  equation  used  for  each  one.  Then  the  individual 


aanaonths  are  suaaed  to  give  a  total  systea  development 
effort.  The  three  equations  are  divided  into  size  measure 
(lines  of  source  code  or  vords  of  object  instructions)  and 
the  life  cycle  phase  in  which  the  estiaate  is  aade  (Concept 
Formulation  and  all  others)  .  If  the  estimate  is  to  be  aade 
using  the  words  of  object  instructions,  the  sane  equation  is 
used  in  all  life  cycle  phases.  Similarly,  for  estimating 
large  systems  (more  than  10,000  lines)  using  lines  of  source 
code  requires  the  use  of  a  different  equation  in  the  Concept 
Formulation  Phase  than  in  the  other  life  cycle  phases. 

The  use  of  the  different  equations  can  be  described  as 
follows  (A,  B,  and  C  refer  to  the  three  different 
relationships) . 


..._u  ,  ,, 

SOFTWARE 

DESCRIPTION 

LIFE  CYCLE  PHASE 
CONCEPT  |  OTHERS 

WORDS  OF  OBJECT  CODE 

A 

A 

LINES  OF  SOURCE  CODE  1 

LARGE  STSTEH  >  10 K  LINES  |  B 

B 

SHALL  SYSTEH  >  10  K  LINES 

B 

c 

The  forms  of  the  estiaating  relationships  are  similar. 
Equations  A  and  B  are  of  the  fora: 

b 

HH  *  a  I 

where 

HU  »  Hanaonths  of  development  effort. 

I  *  either  words  of  object  code  (A)  or  lines  of 
executable  source  code  (B)  . 
a,b  *  Constants  obtained  empirically. 

Equation  C  has  the  fora: 


d  14 

HH  ■  cl  If 


►V- 


I 


k 


Where 

f  »  a  set  of  parameters  describing  the  development 
J  environment. 

c,d  »  constants  obtained  empirically.... 

The  following  guidelines  are  presented  for  selecting  the 
proper  estimating  relationship. 

•  In  Concept  Formulation,  if  the  size  of  the  program  in 
object  code  is  known,  use  the  object  code  estimators. 
They  will  give  more  accurate  estimates  of  manpower 
requirements. 

•  If  accurate  estimates  of  manpower  requirements  are  re¬ 
quired  in  the  Analysis  and  Design  and  subsequent  phases 
of  development,  use  equation  B,  in  source  code,  for 
programs  of  I  >  10,000  and  equation  c,  in  source  code, 
for  programs  with  I  <  1  0,000. 

•  For  budgetary  purposes,  use  the  equation  that  gives  the 
higher  estimate. 

Development  time  is  estimated  using  the  equation 

10001 

9  .667 

92.25  ♦  2331 


Where 

D  »  Seasonable  development  time  in  months 

I  *  number  of  delivered  object  instructions. 

This  relationship  was  obtained  using  regression  on  data 
describing  74  development  projects.  The  time  estimate 

should  describe  "customary"  distributing  of  effort  over  time 
that  is,  it  should  avoid  extremes  of  project  time  compres¬ 
sion  or  expansion. 

It  should  be  noted  that  a  large  portion  of  the  documen¬ 
tation  accompanying  the  description  of  the  DAI  estimating 
procedures  is  devoted  to  discussions  of  factors  that  are 
believed  to  influence  the  cost  of  software  development. 
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These  factors  are  classified  according  to  aspects  of  soft¬ 
ware  and  its  development  environment.  The  factors  are 
grouped  according  to  the  following  "domains": 

•  Requirements 

•  System  Architecture/Engineering 

•  Hanagement 


Outputs 

Cost  Software  Development 

The  estimate  of  total  development  cost  is  based  on 
several  relationships  that  portion  the  cost  into  components 
that  can  be  estimated  by  applying  available  ratios  to  other 
costs  and  factors  such  as  overhead  and  administrative  costs. 
By  the  proper  use  of  relevant  values  for  these  factors  the 
relationships  can  represent  either  goverment  in-house  costs 
or  contractor  development  costs.  A  method  is  described  for 
time  phasing  the  expenditure  that  is  said  to  satisfy  the 
requirements  of  DoD  Directive  5000.  1. 

The  procedure  identifies  costs  that  are  incurred  by  the 
government  during  all  phases  of  the  software  life  cycle 
except  Operation  and  Support.  The  total  development  cost 
includes: 

C  *  C  ♦  C  ♦  C 

CP  VAL  PSD 

where 

C  *  Development  Cost 

C  *  Conceptual  Phase  Cost 

C  «  Validation  Phase  Cost 

VAL 

C  *  pull  Scale  Development  Cost. 

PSD 

Information  is  included  that  relates  the  government  cost 
to  the  contractor’s  full  scale  development  cost.  This  cost 
is  the  one  developed  by  the  formal  software  cost  estimating 
procedure. 


the  cost  of  developaent  is  divided  into  primary  and 
secondary  costs,  thus: 


c  +  C 
P  s 


vhere 


C  »  Cost  of  Developaent 
D 

*  Priaary  cost  (Manpower) 

C  »  secondary  Cost  (Computer,  Docuaentation,  Etc.) 
S 


then. 


an(c  ) 

e 


vhere 


HH  a  Total  Developaent  Man-Honths 

C  a  Average  Labor  Cost 
e 


C  »  J  C,  a  kC- 

S  i*1  1  D 

Therefore:  C  *  (HH)C  (i+k) 

D  e 

vhere 

It  «  Ratio  of  secondary  to  F  ..aary  Costs  (=.075) 

The  total  software  developaent  cost  (does  not  include 
government  Conceptual  and  7alidation  Phase  costs)  includes 
the  costs  of: 

•  Analysis 

•  Design 

•  Code 

•  Code 

•  Debug 

•  Test  and  Checkout 

and  is  proportional  to  tha  total  aan-months  of  development 
effort. 
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This  is  the  primary  output  variable.  It  is  the  basis 
for  the  total  development  cost  estimate  and  it  is  the  value 
from  which  the  distribution  of  effort  by  life  cycle  phase  is 
derived.  The  hours  include  those  directly  related  to  the 
development  of  the  software  system.  They  include  the  direct 
hours  needed  for: 

Analysis  -  interpreting  the  system  requirements  and 
producing  viable  alternative  system  concepts 
Design  -  preparing  detailed  designs  of  the  data  processing 
system  and  the  individual  programs 

Coding  and  Debugging  -  writing  individual  modules  and 
programs  and  performing  individual  tests 

Testing  and  Checkout  -  integrating  the  individual  subsys¬ 
tems  into  a  complete  system  and  conducting  prescribed 
tests  on  the  entire  system. 

The  discussion  of  the  model  does  not  indicate  the  extent 
that  support  and  management  hours  are  included  in  the  total. 
Also,  there  nay  be  some  question  about  the  activities  asso¬ 
ciated  with  concept  development  (e. g.  ,  is  the  test  plan 
furnished  by  the  government  following  the  validation  phase 
or  is  it  developed  as  part  of  the  project) .  As  in  many  cost 
estimating  situations,  the  line  between  concept  analysis  and 
the  evaluation  of  solutions  to  selected  concepts  is  hazy. 

Although  the  DAI  documentation  and  discussions  with  the 
authors  indicate  that  the  model  includes  integrated  system 
testing,  it  appears  that  this  effort  is  not  included  in  the 
original  SDC  data  which  was  the  basis  for  the  curve  fits. 
(76 %  of  the  SDC  data  points  describe  programs  that  do  not 
interface  with  any  other  programs). 

S aliasas  BaislB Basal  lias 

A  nominal  development  time  is  presented  that  implies 
"customary  manloading".  That  is,  the  schedule  does  not 
reflect  either  crash  projects  or  allow  for  unnessary  delays. 
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The  expenditure  of  tiae  and  effort  associated  with  sajor 
project  Milestones  is  pi wen  for  saall  projects  (one  level  of 
supervision)  and  large  projects  (aore  that  one  level  of 
supervision).  The  distributions  are  for  noainal  projects 
and  do  not  allow  for  an;  possible  acceleration  or  delay  of 
the  coapletion  of  the  projact.... 

laeals 

££23£&&  SiiS 

Dll  has  been  very  cars  full  to  describe  the  size  vari¬ 
ables  which  are  the  primary  inputs  to  the  estiaates  using 
the  relationships.  However,  we  should  point  out  that  the 
respondents  to  the  original  SDC  questionnaire  were  not  so 
well  directed  and  it  aay  be  necessary  when  analyzing  the 
structure  of  the  aodel  as  it  relates  to  prediction  accuracy 
that  significant  errors  aay  have  been  introduced  by  this 
failure  to  be  specific.  The  Dll  aodel  aay  not  overcoae  what 
are  inherent  liaitations  in  the  data. 

The  Dll  procedure  calls  for  several  estiaates  in  support 
of  the  DS1RC  process.  It  recognizes  that  the  best  estimates 
of  program  size  are  obtained  later  in  the  development  cycle. 
It  suggests,  then,  that  the  interpretation  of  the  program 
size  changes  during  the  life  cycle  and  that  associated  with 
the  change  are  increases  in  estimating  accuracy.  The  report 
describes  how  the  knowledge  of  the  size  estiaator  changes 
during  the  life  cycle  and  how  this  affects  the  estimating 
precision.  The  precision  associated  with  the  different  size 
measures  during  the  system  development  life  cycle  is  as 
follows. 

Code  that  is  developed  as  part  of  the  project  but  is  not 
delivered  to  the  customer  is  a  source  of  variation  in  the 
estimate  of  the  system  size  and  aust  be  considered. 
However,  no  guidance  is  provided  for  making  any  adjustment 


other  than  citing  that  the  SDC  data  showed  delivered  code  to 
average  77  percent  of  the  developed  code  with  a  standard 
error  of  30  percent. 


software  estimate  1 

|  WHEN  j 

SIZING  BASIS 

|  X  ERROR 

1.  INITIAL  PFCGR AM 
BUDGETARY  ESTIMATE  1 

2.  INDEPENDENT  PROGRAM 

CONCEPTUAL  PHASE 

VALIDATION  PRIOR 
TO  RFP  RELEASE 

TOTAL  OBJECT  CODE 

TOTAL  OBJECT  MINUS 
DATA  AREAS 

UP  TO  200 X* 

UP  TO  100  S 

3*  ttff’RWIiE* 

COMPLETION  OP 
SYSTEM  SPEC 
THROUGH  pcr 

TOTAL  OBJECT  MINUS 
CATA  AREAS  WITH 
ADJUSTMENTS  FOR 

UP  TO  75* 

(IcS1tIs?ipa?2 

POR  THROUGH 
REMAINDER  OP 
DEVELOPMENT 

TOTAL  SOURCE  COOE 

UP  TO  50* 
IMPROVING 

TO  ZERO  AT 
COMPLETION 
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Allowance  must  also  be  aade  for  support  software  devel¬ 
ops  ent  especially  when  working  with  new  hardware. 

Tot al  Object  words 

During  the  Conceptual  Phase  when  very  little  is  known 
about  the  systee  to  be  developed,  the  initial  estimate  is 
nade  using  the  analyst’s  judgement  (usually  by  analogy  with 
previously  developed  systems,  but  other  aethods  are 
possible)  of  the  number  of  object  words  occupied  by  "ever 
program  needed  to  run  and  maintain  the  system  in  the  field". 
This  measure  is  obtainable  from  listings  of  computer  system 
routines  that  build  executable  programs  from  the  output  of 
the  compiler.  Taking  values  from  systems  similar  to  the  one 
being  planned  can  provide  a  basis  for  estimating  the  value. 
Care  should  be  taken,  however,  when  program  overlays  are 
involved.  Also,  extensive  use  of  standard  library  routines 
can  greatly  increase  the  words  of  object  program  size  and 
not  be  representative  of  a  comparable  increase  in  develop¬ 
ment  effort. 


laiai  aiJssi  tails  iUms  s&is  imi 

The  memory  space  occupied  by  an  executable  program  is 
composed  of  locations  containing  instructions  and  locations 
reserved  for  the  data  upon  which  the  program  will  operate. 
Sometimes  the  data  storage  areas  are  significantly  larger 
than  the  area  occupied  by  the  actual  instructions.  Oil 
suggests  that  the  effort  required  to  develop  the  programs  is 
more  closely  related  to  the  size  of  the  instruction  space 
than  to  the  size  of  the  combined  data  and  instruction 
storage.  However,  as  in  the  case  of  the  total  object  words, 
there  is  no  evidence  of  this  distinction  being  made  in  the 
original  derivation  of  the  estimating  procedures.  llso, 
there  is  no  guidance  provided  on  how  to  apply  the  additional 
information  when  preparing  cost  estimates.  Some  computer 
system  executive  processing  routines  provide  this  informa¬ 
tion.  However,  many  don't  and,  therefore,  it  would  be  very 
difficult  to  obtain  comparable  historical  information  to 
guide  new  estimates. 

£2S  2telg££.  gQ£&§  AIMS  h£eas 

Only  the  writing  of  new  code  contributes  to  the  software 
development  effort  (if  code  written  to  modify  existing 
modules  is  counted  as  new  code)  .  To  account  for  the  work: 
done  to  adapt  existing  code  to  a  new  system,  which  includes 
analyzing  the  code  and  decid:.ng  how  to  modify  it,  any 
existing  module  that  will  result  is  less  than  50  percent 
utilization  of  existing  code  is  considered  to  be  entirely 
new. 

flat  saaisa  lisas 

Counts  of  new  source  lines  written  (whether  in  a  higher 
order  or  machine  oriented  language)  can  be  obtained  from 
compiler  listings,  measuring  card  decks  or  text  editors.  It 
is  one  of  the  easiest  measures  of  size  to  obtain.  As  in  the 
previous  case,  modules  containing  less  than  50  percent 
reused  code  are  considered  to  be  new. 


Developaent  Environ  lent 

For  estiaates  aad«  using  lines  of  source  code  where  the 
size  is  less  than  10,000  lines,  the  estiaating  relationship 
includes  a  nuaber  of  factors  describing  the  developaent 
environaent.  These  are  included  in  the  estiaate  when  the 
indicated  itea  is  to  be  part  of  the  developaent  process.... 
fl  Special  Display 

f2  Detailed  Definition  of  Operational  Reguireaents 

f 3  Change  to  Operational  Reguireaents 

f 4  Real  Tiae  Operation 

f5  CPU  Heaory  Constraint 

f 6  CPU  Tiae  Constraint 

f 7  First  SH  Developed  on  CPU 

f 8  Concurrent  Developed  on  CPU 

f9  Tiae  Share  Verus  Batch  Processing  in  Developaent 
flO  Developer  Using  Coaputer  at  Another  Target  coaputer 
fll  Developaent  at  Operational  Site 

f 12  Developaent  Coaputer  Different  froa  Target  Coaputer 
f 13  Developaent  at  Hore  than  One  Site 
f 14  Prograaaer  Access  to  Coaputer 

After  analyzing  the  aethod  used  by  DAI  to  obtain  their 
estiaating  relationships  and  after  coaparing  their  defini- 
tions  of  input  and  output  variables  with  the  original 
sources  of  data,  it  is  clear  that  there  are  discrepancies 
between  the  way  the  data  are  being  applied  and  what  they 
originally  represented.  DAI  does  not  explicity  justify 
their  approach  but  their  presentation  of  the  estiaating 
procedure  does  give  consideration  to  errors  arising  froa 
differing  definitions  of  the  variables. 

DAI  seeas  to  be  saying  that  consistent  use  of  the  esti- 
aating  procedures  regardless  cf  how  they  were  obtained  will 
produce  results  with  at  least  a  predictable  error.  That  is, 
knowing  the  range  of  error  that  can  occur  because  of 


differences  in  definitions  and  ability  to  predict  the  in  pat 
variables  will,  when  applied  to  the  given  estimating  rela¬ 
tionships,  produce  estimates  with  precision  that  is  in 
accordance  with  previous  experience.  DAI  further  substanti¬ 
ates  the  approach  of  throwing  all  the  error  into  the  ability 
to  define  the  input  by  presenting  standard  error  values  for 
the  size  variables  at  different  tines  in  the  life  cycle. 

E.  FARE  AMD  ZAGORSKI  BODEL 
9egcr4.Ptj.on  of  the  Model 

System  Development  Corporation  completed  several 
projects  for  the  Air  Force,  Electronic  Systens  Division  in 
which  they  attempted  to  develop  methods  for  predicting  the 
cost  of  software  development.  The  Farr  and  Zagorski  model 
represent  an  intermediate  stage  in  the  program. 

Osino  historical  data  from  internal  projects  and  from 
other  organizations,  the  SDC  team  systematically  tested  over 
100  variables  to  learn  if  they  were  satisfactory  predictors 
of  program  design,  coding  and  debugging  effort. 

Farr  and  Zagorski  published  three  equations  which  were 
determined  to  be  the  best  predictors  tested  up  to  that  time. 

MB  *  2.7X  ♦  12 IX  ♦  26  X  ♦  12X  «-22X  -  497  (1) 

I  2  3  4  5 

BB  *  2.8X  ♦  1.3X  ♦  33  X  -  17X  ♦  10X  ♦  X  -  188  (2) 

6  7  3  8  9  10 

BB  *  8.4X  „  +1.8X  ♦  9.7X  -  3.7X  -  42  (3) 

II  12  3  13 

Definition  of  Output 

BB  is  the  number  of  mansion ths  needed  to  design  ,  code 
and  debug  a  single  program.  The  effort  begins  when  a 
programmer  cr  analyst  is  given  a  complete  operational  speci¬ 
fication  for  a  program  and  it  ends  when  the  program  is 
released  for  integrated  system  testing. 
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fififlniilgas  2l  lams 

Z  ■  number  of  instractions  in  original  estimate  (in 
thousands) 

*  subjective  rating  of  information  systee  complexity 
(scale  1-5) 

X ^  *  number  of  document  types  delivered  to  customer 

X  *  number  of  document  types  for  internal  use 

4 


number  of  computer  words  needed  to  store  program 
data  (log^) 

number  of  instructions  in  delivered  program  (in 
thousands) 

number  of  nun-miles  for  travel  (in  thousands) 

system  programmer  experience  (average  of  total  years 
of  experience  with  the  computer,  language,  and 
application) 

number  of  display  consoles 

percent  of  instructions  new  to  this  program  (not 
re-used  from  preveios  versions) 

number  of  instructions  to  perform  decision  func¬ 
tions  (in  thousands) 

number  of  instructions  to  perform  nondecision 
functions  (in  thousands) 

programmer  experience  with  this  application  (aver¬ 
age  number  of  years). 


F.  W CL VERT ON 


iki  aojal 

Estimates  of  routine  size  are  converted  to  costs  using 
cost  per  instruction  values  that  are  functions  of  the 
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routine  type  and  complexity.  The  costs  are  fully  burdened 
and  when  sussed  for  all  the  system  routines  represent  the 
total  system  development  cost.  Development  extends  from 
analysis  and  design  through  operational  demonstration.  k 
matrix  of  ratios  is  used  to  allocate  the  total  cost  to  7 
phases  with  each  phase  divided  into  up  to  25  activities. 
This  allocation  is  compared  from  the  standpoints  of  staff , 
schedule ,  and  general  credibility. 

The  model,  then,  is  a  combination  of  formal  algorithm 
and  judgement.  It  has  been  used  successfully  at  TEW.  is 
described  by  Wolverton,  it  features  a  data  base  of  histor¬ 
ical  data  that  provide  the  necessary  cost  per  instruction 
and  allocation  values.  The  procedure  is  adaptable  to  any 
new  environment  by  creating  a  new  data  set  representing 
local  definitions  of  phases  and  activities  and  burdened  cost 
conventions.  In  fact,  Wolverton  cautions  that  the  given 
values  cf  cost  per  instruction  are  for  illustration  and 
users  should  prepare  their  own  values. 

TH1  has  computerised  the  maintenance  of  the  cost  data 
base  and  the  allocation  process.  Siven  the  inputs  of  size 
and  complexity,  the  system  calculates  the  cost  allocations 
and  facilitates  any  subsequent  adjustments.  Since  most 
models  are  used  in  a  similar  manner,  even  if  the  procedure 
for  using  the  model  does  not  say  so,  there  should  be  no 
compromise  of  the  model's  performance  if  the  evaluation  is 
based  on  a  single  estimate  of  costs.  Other  adjustments  that 
are  necessary  to  execute  the  model  in  different  environments 
will  be  discussed  later. 

The  estimating  procedure  begins  by  identifying  all  the 
routine  comprising  the  system.  Each  routine  size,  category, 
and  relative  degree  of  difficulty  are  estimated  by  knowl¬ 
edgeable  persons. 


The  categories  that  have  "stood  the  test  of  usage"  at 
TRi  are: 

•  Control  routine 

•  Input/Output  routine 

•  Pre  or  Post  algorithn  processor 

•  Algor iths 

•  Data  Hanageaent  routine 

•  Tiae-Critical  processor 

Relative  difficulty  is  indicated  by  six  levels  depending 
on  whether  a  routine  is  Old  or  New  and  then  by  sinply:  Easy, 
Hediua  or  Hard. 

... .Halt ip lying  the  cost  per  instructin  for  each 
routine  by  its  nuaber  of  object  instructions  and  suaaing  the 
products  for  all  the  routines  yields  the  estiaated  total 
dev9lopaent  cost. 

The  developaent  cost  is  allocated  to  the  following  7 
phases  using  proportions  for  each  phase  that  were  obtained 
froa  the  historical  data  base. 

A.  perforaance  and  Design  Reguireaents 

3.  lapleaentation  Concept  and  Test  Plan 

C.  Interface  and  Data  Reguireaents  Specification 

D.  Detailed  Design  Specification 

E.  Coding  and  Auditing 

P.  Systea  Validation  Testing 

G.  Certification  and  Acceptance  Deaonstration 

Then,  the  cost  for  each  phase  is  divided  into  up  to  25 
activities. . . . 

A  aatrix  of  computer  hours  by  phase  and  software  type  is 
used  to  estiaate  coaputer  usage  costs  for  developaent. 

The  given  cost  values  are  in  1972  dollars.  The  value  of 
cost  results  froa  applying  "bid  rates"  to  labor  costs  which 


accounts  for  fringe  benefits,  overhead,  administrative 
expenses  and  other  indirect  costs.  Documentation  and  travel 
costs  are  added  to  the  labor  costs.  Finally,  estimates  are 
made  of  the  computer  costs.  The  distribution  of  the  costs 
by  phases  and  activities  vere  described  above. 

Development  Effort 

Cost  is  not  a  suitable  basis  for  evaluating  the 
different  software  estimating  models  because  of  differences 
in  accounting  practices  among  organizations  and  because  of 
inflation.  Therefore,  the  Wolverton  cost  values  were 
converted  to  manmonths  using  an  average  burdened  cost  per 
manmonth  of  $4600.  This  value  was  obtained  from  the  article 
describing  the  THW  estimating  procedure  and,  therefore, 
should  be  representative  of  the  cost  environment. 
laB&tg 

Qilssi  lastcasUoas 

The  model  input  measure  of  size  is  applied  to  programs 
or  routines.  These  are  taken  to  be  functionally  distinct 
elements  of  a  system  that  would  be  developed  independently 
then  intergrated  into  the  delivered  system.  It  is  expected 
that  these  would  be  independently  operable  using  test 
drivers.  Such  a  definition  is  consistent  with  industry 
usage.  The  reference  document  is  not  specific  on  this 
point.  The  term  "instructions"  is  taken  literally.  This 
means  estimating  the  number  of  instructions  in  the  execu¬ 


table  program  exclusive  of  any  data  areas.  The  number  of 
instructions  may  be  estimated  by  obtaining  the  words  of 
memory  occupied  by  the  executable  code  and  dividing  by  the 
average  words  per  instruction. 

Software  Categories 

Each  routine  is  characterized  according  to  one  of  the 
following  categories: 


Controls  execution  flow  and  is 


C .  Control  Routine . 
nontiae  critical. 

I.  Input/Output  Routine.  Transfers  data  into  and  out  of 
coaputer 

P.  Pre-or  Post  Algor  it  h  a  ftrocesso^.  Hanipulates  data 
for  subsequent  processing  or  output. 

A.  Aluor it ha.  Performs  logical  or  mathematical  opera¬ 
tions. 

D.  Sala  Management  Ro  utine.  Manages  data  transfer 
within  the  computer. 

T.  Time  Critical  Processor.  Highly  optimized  machine 
dependent  code, 
asaisg  o£  24nigaitj[ 

Wolverton  indicates  that  any  numeric  representation  of 
complexity  may  be  used.  The  main  purpose  is  to  distribute 
the  cost  per  instruction  values  over  the  range  of  experience 
for  a  given  category  of  software.  He  suggests  a  simple 
designation  of  old  or  new,  depending  on  a  loose  interpreta¬ 
tion  of  the  amount  of  reusable  code,  and  easy  medium  or  hard 
compared  with  other  programs  in  the  same  category. 
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B.  W.  Wolverton  studied  several  software  cost  estiaating 
models  while  working  for  TRW  in  an  effort  to  deteraine  that 
aodel  which  would  best  predict  those  costs  associat  with 
software  development.  This  appendix  consists  of  e  srpts 
from  his  review  of  some  of  these  aodsls. 

B.  BOEING  COMPOTES  SERVICE  COST  MODEL 
£3g£2Sa 

Boeing  Coaputer  Services  (BCS)  designed  this  analytical 
aodel  to  provide  an  estimate  at  proposal  preparation  tine  of 
the  number  of  aanaonths  needed  to  design  a  coaputer  program. 
BCS  developed  the  aodel  for  use  as  an  internal  guideline  to 
cross-check  the  traditional  bottom-up  estimate  made  by  their 
proposal  manager.  The  bottom-up  estimate,  with  its  WBS  was 
tacitly  assumed  to  be  more  accurate  and  the  model  served  to 
aid  in  independently  justifying  the  proposal  manager's 
estimate. 

While  under  contract  to  BIDC,  Boeing  used  their  cost 
aodel  to  test  several  hypotheses  about  the  cost  benefit 
attributable  to  modern  programming  practices  (Black,  et  al. , 
1977;  Black,  1978).  BCS  derived  and  calibrated  their  aodel 
against  internal  software  projects  using  traditional 
programming  practices.  This  aodel  has  received  wide-spread 
exposure  as  part  of  the  DOD's  embedded  computer  resources 
DSIRC  guidebook  (DeBoze,  19  77). 


Size  of  computer  software  in  units  of  delivered 
source  statements.  The  BCS  model  assumes  that  a 
"statement"  is  one  fully  checked  tested,  and  docu¬ 
mented  statement  coded  in  a  selected  language.  The 
choice  of  high-level  language  can  have  a  significant 
effect  on  the  development  cost,  but  ordinarily  affects 
only  portions  of  the  total  task. 

Type  of  software  to  developed.  BCS  observed  some 
combination  of  five  generic  functions.  Each  "type" 
has  its  own  group  productivity  rate.  The  specific 
software  type  and  productivity  rates  are  as  follows: 


•  Mathematical  Opns 

•  Report  Generation 

•  Logic  Operations 


aanmonths/ 

1 00  source  statements 


8  aanmonths/ 
1000  source  ! 


statements 


source  statements 


Signal  Processing,  20  aanmonths/ 

Data  Reduction  1000  source  statements 

Re^l-Time.  Executive  or  40  manmonths/ 

Avionics  Interfacing  1000  source  statements 


The  decreasing  productivity  is  caused  by  the 
increasing  complexity  of  the  type  of  software  being 
developed. 

Tasks  to  be  accomplished  in  the  computer  software 
development,  are  distributed  by  the  BCS  model  as 


follows: 


Task 


the  BCS  model 


%  Total  Cost 


Requirements  Definition 
Design  and  Specification 
Code  Preparation 
Code  Checkout 
Integration  and  Test 
System  Test 


The  numerical  distribution  opposite  the  task  does  not 
consider  reuse  and  sophisticated  debug  tools.  The 
distribution  is  not  necessarily  a  rectilinear  function 
of  tiae,  but  is  intended  to  be  used  as  a  guideline  for 
schedule  preparation.  Docuaentation  is  not  included 
in  this  estiaating  procedure  and  aust  be  estiaated  by 
scae  other  aethod,  not  defined  in  the  aodel  itself, 
and  added  to  the  aanpower  estiaates. 
d.  Adjustaent  of  the  labor  estiaates  is  acconplished  by 
aeans  of  table  lookup  aultipliers  given  in  Table  VIII. 
All  teras  are  assuaed  by  the  aodel  developer  to  be 
self-explanatcry. 

Coaputational  Procedure 

Using  this  aodel,  Prograa  Office  personnel  would  esti- 
aate  how  auch  of  the  total  OPP  software  is  closest  repre¬ 
sented  by  one  of  the  five  generic  types  of  software.  In 
practice,  estiaating  the  size  and  type  would  be  based  on 
past  experience  with  siailar  projects  that  have  been 
adjusted  to  the  new  application.  Everything  associated  with 
the  aanaonth  estiaate  flows  froa  this  first  step. 

Table  VIII  provides  the  estiaator  with  phase-sensitive 
aultipliers  for  adjusting  the  baseline  aanaonths  estiaate. 
The  user  should  be  alert  to  stringent  sizing  or  tining  liai- 
tations.  These  effects  should  be  estiaated  by  soae  other 
procedure  (not  given)  and  added  to  the  baseline  aanaonth 
estiaate. 

After  individual  labor  costs  have  been  adjusted  by  use 
of  the  table,  the  BCS  aodel  suas  up  the  individual  estiaates 
and  arrives  at  the  total  labor  cost  for  the  project. 
Coaputer  tiae  is  estiaated  by  a  rula  of  thuab  that  approxi- 
aately  three  hours  of  stand-alone  coaputer  tiae  will  be 
spent  per  aanaonth. 
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Out  out 

The  fundamental  output  is  the  total  aanaonths  estisated 
for  the  planned  software  project.  In  turn,  the  total 
■ansonths  are  spread  over  a  six  stage  developsent  cycle  fros 
requirements  definition  to  systes  test. 

Although  acceptable  engineering  accuracy  in  estiaating 
total  aanaonths  is  claimed  by  the  aodel  developers  for 
traditional  prograaaing  practices  (c.  1970),  the  examples  of 
estiaating  accuracy  are  not  encouraging  for  modern  program¬ 
ming  practices.  In  other  words,  the  intent  of  the  BCS  model 
is  to  show  how  much  a  new  project  would  have  cost  if  done 
the  old  way.  Presumably  the  lower  observed  cost  is  due  to 
the  new  design  methodologies.  Output  results  for  five 
projects  given  by  BCS  are  shown  in  Table  IX.  A  guideline  is 
to  try  this  aodel  cn  some  historical  data  and  compare  the 
accuracy  of  predicted  versus  actual  aanaonths  before 
attempting  to  use  it  in  practice.... 

TABLE  IX 

Forecasted  versus  Actual  Costs  for  the  BCS  Model 


Project 

Forcast 

Total  aanaonths 

Actual 

Total  Manmonths 

Forecast/Actual 

Ratio 

A 

419.7 

71.0  " 

5.9 

B 

2288.5 

991.7*# 

2.  3 

C 

51.5 

43.  8 

1.2 

D 

3298.7 

514.  8** 

6.4 

E 

. 

7.9 

7-3  . 

1.  1 

#*  Conta: 
actuaJ 

.ns  some  estimate- 
.s 

-to-coaplete  data, 

along  with 
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C.  IBM  WALSTOM-FSLIX  COST  MODEL 

EK2&3& 

Ralston  and  Felix  conducted  experiments  on  60  coapleted 
software  development  projects  in  their  search  for  a  method 
of  estimating  programing  productivity  (Ralston-Felix,  1977). 
The  purpose  of  this  effort  was  to  estimate  the  rate  of 
production  of  lines  of  code  by  projects,  as  influenced  by 
project  conditions  and  requirements. 

Five  specific  objectives  of  the  Ralston-Felix  model  are 

a.  To  evaluate  improved  programming  technologies. 

b.  To  provide  support  for  proposals  and  contract 
performance. 

c.  To  gather  historical  records  of  the  software  devel¬ 
opment  work  performed. 

d.  To  provide  programming  data  to  management. 

e.  To  foster  a  common  programming  terminology. 

Completed  projects  in  the  Ralston-Felix  data  base  ranged 

in  size  from  4,000  to  467,000  delivered  source  lines  of  code 
and  in  effort  from  12  to  11,758  manmonths.  Applications 
programs  included  realtime  process  control;  interactive, 
report  generators;  data  base  control;  and  message  switching 
programs.  Twenty-eight  different  high-level  languages  and 
66  different  computers  are  represented  in  their  data  base. 
This  is  an  outstanding  example  of  a  closed-form  model 
obtained  by  linear  regression  analysis  of  a  large  and 
diverse  body  of  actual  software  projects.  Some  further 
technical  work  is  required  to  extend  the  findings  of  Ralston 
and  Felix  to  the  specialized  needs  of  avionics  software. 
The  additional  work  to  be  done  in  calibration  of  the  model 
will  be  discussed  in.  ..Comp utational  Procedure. 

a.  Number  of  lines  of  delivered  source  code.  Source 
lines  are  80- character  source  records  provided  as 


input  to  a  language  processor*  Job  control  languages* 
data  definitions*  link  edit  language,  and  comment 
lines  are  included.  Boused  code  is  not  included, 
b.  From  the  raw  data  provided  by  the  60  projects,  a  set 
of  68  variables  vas  selected  for  analysis  to  find 
which  ones  were  significantly  related  to  productivity. 
Twenty-nine  of  the  variables  showed  a  significant 
correlation  with  productivity  and  have  been  retained 
for  use  in  esti sating .... 

. . The  nodel  user  is  asked  to  answer  a  multiple- 

choice  question  in  his  response  to  the  statesent:  User 
participation  in  definition  of  requirements  is:  none, 
some,  much.  In  the  origional  analysis  the  mean 
productivity  was  computed  for  the  60  completed 
projects  for  which  no  user  participation  was  reported 
and  found  to  be  «91  D  SL/HH.  The  mean  productivity  for 
all  projects  that  reported  some  user  participation  was 
267  DSL/KH,  and  the  mean  productivity  for  those 
reporting  much  user  participation  was  205  DSL/HH.  The 
absolute  value  of  the  change  in  productivity  from  no 
user  participation  to  much  user  participation  is  found 
to  be  286  DSL/HR.... 

figasala&Lgml  gsgsaflais 

The  Walston-Felix  cost  nodel  can  aid  Program  Office 
personnel  in  estimating  five  project  parameters:  produc¬ 

tivity,  schedule,  cost,  quality,  and  si2e  of  the  software 
product  to  be  delivered.  One  difficulty  is  in  identifying 
and  measuring  independent  variables  that  can  be  used  to 
estimate  the  desired  variables,  such  as  estimating  the  size 
of  the  software  product  to  be  delivered.  *e  take  the  point 
of  view  that  the  size  of  the  software  product  to  be  deliv¬ 
ered  can  be  independently,  albeit  with  difficulty,  estimated 
from  the  internal  historical  data  base  associating  avionics 


function  with  size  (Battelle,  1978)  or  avionics  function 
with  software  requiresents  (Heninger,  et  al. ,  1978). 

Productivity  is  a  significant  variable  in  all  software 
estimating  processes.  Progressing  productivity  is  defined 
here  as  the  ratio  of  the  delivered  source  lines  of  code 
(DSL)  to  the  total  project  effort  in  sansonths  (HH)  required 
to  produce  the  delivered  product.  Total  sansonths  covers 
the  management,  administration,  analysis,  operational 
support,  docusentation,  design,  coding,  and  testing  effort 
expended  in  the  development  phase.  Analytical  results  are 
derived  at  start  of  work,  PDR,  sidway  through  software 
developaent,  at  acceptance  test  completion,  and  every  three 
souths  during  the  service  or  maintenance  phase. 

The  29  variables. •• are  combined  into  an  index  based  on 


the  effect  of  each  variable  on  productivity  from  previous 
analysis.  The  productivity  index  is  computed  as  follows: 


■KiVi 


where 

I  *  productivity  index  for  a  project 

■  question  weight,  calculated  as  0.5  log^PC)^ 

(PC)  ^  *  productivity  change  indicated  for  a  given 
question  i...  . 

»  question  response  (+1,  0,  or  -1),  depending  on 
whether  the  response  indicates  increased,  non- 
inal,  or  decreased  productivity. 

....The  data  set  is  analyzed  by  ordinary  least  squares 
and  the  standard  error  of  estimate,  or  standard  deviation  of 
residuals,  is  shown  as  dashed  lines.  In  the  data  sample 
studied,  the  productivity  index  ranged  from  -4  to  +4 
(private  communication  with  C.  Ralston).  The  Air  Force 
model  user  would  determine  his  own  productivity  index  for  a 
single  project  by  answering  the  29  questions.. . and  by 


calculating  I  according  to  the  above  foraula.  He  then 
multiplies  his  average  productivity  for  all  past  avionics 
software  in  his  data  base  by  the  productivity  index  for  the 
acquisition  at  hand. 

If  the  Prograa  Office  has  a  historical  data  base  of  aany 
projects,  the  total  effort  can  be  deterained  by  a  least 
squares  fit  and  the  regression  equation  froa  the  Prograa 
office* s  own  internal  data  analysis  at  the  point  I  *  0, 

DSL/HH  »  274,  using  the  coordinate  systea....  &  statis¬ 
tical  analysis  prograa  such  as  the  Statistical  Package  for 
the  Social  Sciences  (a  product  of  SPSS,  Inc.)  would  be 
helpful.  SPSS  will  also  provide  other  descriptive  statis¬ 
tics  such  as  the  standard  error  of  the  linear  regression 
1 m  e. ... 

The  statistics.. .are  given  by  medians  and  quartiles 
because  of  the  variability  in  the  aeasureaent  data.  Note 
that  the  aedian  productivity  (I  *  0)  is  274  DSL/HH.  The 
aedian  for  the  size  of  the  delivered  software  product  is 
20,000  lines;  50  percent  of  the  projects  reported  that  the 
size  of  their  delivered  code  ranged  froa  10,000  to  59,000 
lines.  Resources  for  project  development  are  shown.  The 
error  detection  results  are  for  the  distribution  of  errors 
reported  during  the  development  period.... 

The  amount  of  calendar  time  to  allow  for  the  development 
of  software  is  difficult  to  express  from  a  closed-form 
model.  However,  the  equation  for  project  duration  in  months 
as  a  function  of  total  effort  in  aanmonths  was  found  to  be; 

„  0. 35 

a  »  2.47  s 

where, 

H  *  duration  in  months,  for  full-scale  development 
E  »  effort  in  aanmonths,  for  full-scale  development. 
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Froa  the  data  collected  for  service  projects,  certain 
descriptive  statistics  were  calculated. . .  •  The  interpreta¬ 
tion  is  the  saae  as  before:  sedian  data  and  quartile  data 

are  presented  due  to  the  scatter  in  the  raw  reports.  Ho 
predictive  relationships  are  given  for  service  projects. 

Documentation,  as  defined  in  this  sodel,  consists  of 
prograe  functional  specifications  and  descriptions,  users* 
guides,  test  specifications  and  results,  flowcharts,  and 
prograe  source  listings  that  are  delivered  as  part  of  the 
docuaentation.  To  a  close  approximation,  the  lea3t  squares 
equation  for  the  nuaber  of  pages  of  delivered  docuaentation 
varies  directly  as  the  nuaber  of  lines  of  source  code;  that 
is 

1.01 

D  *  49  L 

where, 

D  »  pages  of  docuaentation,  including  source  listings 
L  «  thousands  of  source  code  lines 

QaSEfl! 

The  major  outputs  available  to  the  aodel  user  are  as 
follows: 

a.  Total  effort  in  man  months  required  to  produce  the 
lines  of  source  code. 

b.  Duration  of  project  in  months. 

c.  Use  of  improved  programming  technologies  expressed  as 
a  percentage  of  code  developed  using  each  rechnique. 

d.  Estimated  productivity  of  project  as  influenced  by 
project  environment  and  requirements. 

e.  Pages  of  docuaentation  for  the  intended  project, 
including  pages  of  source  listings  delivered  as  part 
of  the  docuaentation  requirements. 

f.  The  results  do  not  support  answers  to  certain 
project  attributes  implied  by  the  data  coeffi¬ 
cients.  .. because  of  cross-correlation  effects  (i.e.. 


5 


the  individual  attributes  are  not  statist icily  inde¬ 
pendent).  For  ezaaple: 

1.  Chief  programmer  teaa. 

2.  Top  down  development. 

3.  Structured  prograaaing. 

4.  Design  and  code  inspections. 

The  contribution  of  each  attribute  could  not  be  taken 
individually  because  in  the  definition  of  chief 
prograaaer  teaa  the  other  techniques  are  iaplied. 
g.  other  descriptive  statistics  can  be  inferred  froa 
study  of  the  report  itself;  for  example,  the  cost  of 
coaputing  tiae  and  the  average  nuaber  of  people  (total 
aanaonths  of  effort  divided  by  the  duration)  as  a 
function  of  the  total  effort.  The  responsibility  of 
relating  the  lines  of  executable  asseably  code  to 
lines  of  delivered  source  code  rests  with  the  aodel 
user....  A  scaling  law  for  the  Walston-Felix  aodel  can 
be  derived  froa  internal  avionics  historical  data. 

D.  POTBiH'S  SOFTWARE  LIFE  CYCLE  COST  HODBL  (SLIB) 

Eacsaaa 

k  descriptive  cost  aodel,  coupled  with  inforaed  opinion, 
will  aid  in  answering  top-level  aanageaent  questions  about 
the  developaent  of  OFP  software.  Descriptive  statistics 
associated  with  expected  OFP  software  cost,  developaent 
tiae.  Banning  levels,  and  perturbations  about  these  esti- 
aates  are  significant  aanageaent  interests  at  pre-5FP  tiae. 
The  Air  Force  can  specify  a  useful  lifetiae,  say  10  years, 
and  obtain  a  quantitative  cost  estimate  of  the  OF?  software 
life  cycle  subject  to  the  assuaptions  of  the  aodel. 


IA&& 

Three  inpat  paraeeters  are  required  to  calibrate  this 
aodel*s  technology  constant  (Ck)  for  avionics  applications. 
The  F-1 1 1  data  point... vas  the  basis  for  this  calibration. 
The  three  data  points  are: 

a.  Basher  of  delivered  lines  of  executable  source  code- 
not  including  consents:  2  2,100. 

b.  Husber  of  nansonths  for  developing  software:  805. 

c.  Husber  of  calendar  sonths  for  developing  software:  33. 
The  user  is  prospted  for  all  inputs  by  the  EDITOB  built 

into  the  SLIH  cost  so del.  seventeen  on-line  inputs  required 
for  this  sodel  are  as  follows: 

a.  Enter  title  of  software  systes.  Avionics,  F-1 11 

b.  Enter  start  date  (HHYY) •  0174 

c.  Enter  the  fully  burdened  labor  rate  ($/HY)  at  your 
organization.  60000 

d.  Enter  the  standard  deviation  of  your  labor  rate 

(S/HY) .  6000 

e.  Enter  the  anticipated  inflation  rate  as  a  decinal 

fraction.  0.065 

f.  Enter  the  proportion  of  developsent  that  will  occur  in 
on-line,  interactive  node.  0 

g.  Enter  the  proportion  of  the  developsent  cosputer 

that  is  dedicated  to  this  systes  developsent  effort. 

0.2 

h.  Enter  the  proportion  of  the  systes  that  will  be 

coded  in  a  HOL.  0 

i.  Enter  the  nusber  corresponding  to  the  priaary 

language  to  be  used.  (Twelve  choices  are  given.)  10 
»  asseably  level  language. 

j.  Enter  the  nusber  corresponding  to  the  type  of  your 
systes.  1 

1.  Real-tiae  or  tiae  critical  systes 

2.  Operating  systes 


3.  Command  and  control 

4.  Business  application 

5.  Telecommunication  and  message  switching 

6.  Scientific  system 

7.  Process  control. 

Choose  the  response  belov  which  best  describes  your 
system.  2 

1.  The  system  is  entirely  new,  with  many  interfaces, 
and  must  interact  within  a  total  management  infor¬ 
mation  system  structure. 

2.  This  is  a  new  stand-alone  system.  It  is  simpler 
because  the  interface  problem  with  other  systems 
is  eliminated. 

3.  This  is  a  rebuilt  system  with  large  segments  of 
existing  logic.  The  primary  tasks  are  recording, 
integration,  interfacing,  and  minor  enhancements. 

4.  This  is  a  composite  system  made  up  of  a  set  of 
independent  subsystems  with  few  interactions  and 
interfaces  among  them.  Development  of  the  inde¬ 
pendent  subsystems  will  occur  as  a  considerable 
overlap. 

5.  This  is  a  composite  system  made  up  of  a  set  of 
independent  subsystems  with  a  minimum  of  interac¬ 
tions  and  interfaces  among  them.  Development  will 
occur  in  parallel . 

Enter  the  the  proportion  of  memory  of  the  target 
machine  that  will  be  utilized  by  the  software  system. 
0.85 

Enter  the  proportion  of  real-time  code.  1 
Below  is  a  set  of  modern  programming  techniques 
that  may  be  used  on  a  software  development  project. 
Beside  each  are  three  possible  responses  indicating 
the  degree  of  usage  on  your  system.  1 


Technique 


Response 


Structured  Programming 

D 

< 

25% 

2) 

25 

-75% 

3) 

>7511 

Design  and  Code  Inspection 

D 

< 

25% 

2) 

25 

-75% 

3) 

> 

75% 

Top-dcvn  Development 

1) 

< 

25% 

2) 

25 

-75% 

3) 

> 

75% 

Chief  Programmer  Teams 

D 

<25% 

2) 

25 

-  75% 

3) 

>75% 

Below  are  two  indicators  of  personnel  that  can 
ispact  the  cost  and  tine  to  do  a  project.  Beside  each 
are  three  possible  answere  indicating  the  degree  of 
experience.  2 


Personnel  Experience 


Overall  Skill  and  Qualification 

With  Development  Computer 


Response 

1)  Minimal 

2)  Average 

3)  Extensive 
1)  Minimal 


Enter  sizing  information  in  one  of  two  forms: 

1.  An  overall  range  of  sizes,  or 

2.  Ranges  of  size  on  a  module-by-module  basis. 

Enter  1  or  2  to  indicate  how  sizing  data  should  be 
entered.  1 


q.  Enter  the  lowest  possible  and  highest  possible  size  in 
source  stateaents.  1  8100,  26100 
Computational  Procedure 

Total  effort  can  be  determined  froa  the  software  equa¬ 
tion  developed  by  L.  H.  Putnam  (Putnaa,  1978;  Putnaa  and 
Fitzsimmons,  1979) .  The  software  equation  is  modified  by 
the  environmental  input  parameters,  items  f  through  o.  The 
software  equation  is: 


S  »  C  K 


s  k 


1/3t4/3 

a 


where, 

S  *  nuaber  of  delivered  lines  of  executable  source 
s 

code,  not  including  consents 
*  a  state  of  technology  constant;  previous  exper¬ 
ience  with  computer  response  tines  and  pro- 
gaaning  practices  gives: 

*  754  for  avionics,  asseably- level  language 

*  4984  for  "1973-style"  arbitrary  develop¬ 
ment 

*  10040  for  "1979-style"  structured  develop¬ 
ment. 

K  *  Hayleigh/Norden  life  cycle  effort  parameter  in 

units  of  manmonths  or  manyears 

t  »  Rayleigh /Horde n  time  parameter.  Time  at  which 
d 

peak  manpower  nominally  occurs  for  large  soft¬ 
ware  projects.  Mathematically,  it  is  the  peak 
of  the  curve, 

2  2 

2  -t/2t 

I'  *  K/t  te  d 
d 


2 

K/td 


system  difficulty,  or  ratio  of  total  effort  to 
development  time  squared. 


The  software  equation  is  used  to  obtain  engineering 
quality  estimates  during  the  early  phases  of  a  software  pro¬ 
ject.  The  software  equation  is  solved  using  a  gradient  con¬ 


straint,  K  »  VD  t^,  where  the  magnitude  of  the  difficulty 

d 

gradient  is  eapirically  found  for  a  particular  development 
environment.  Honte  Carlo  simulation  is  used  to  generate 
descriptive  statistics  associated  with  the  effort,  develop¬ 
ment  time,  and  development  cost.  The  standard  deviations 
are  used  in  calculating  risk  profiles. 

The  effort,  time,  and  cost  point  estimates  can  be 
presented  in  the  form  of  probability  plots  assuming  a  gaus- 
sian  distribution.  All  that  is  needed  is  an  extimate  of  the 
expected  value  (plotted  at  the  50  percent  probability  level) 
and  the  standard  deviation  (plotted  offset  from  the  expected 
value  at  the  16  percent  probability  level)  to  generate  the 
probability  line  on  ordinary  probability  paper.  Then  one 
can  determine  for  example,  that  there  is  a  90  percent  prob¬ 
ability  that  the  software  development  will  not  take  more 
than  x-manmonths  of  effort.  When  repeated  for  all  prob¬ 
ability  levels  of  interest,  one  has  a  risk  profile  for  that 
estimate. 

The  tradeoff  law  can  be  obtained  from  the  software  equa¬ 
tion  by  solving  for  K.  with  a  Honte  Carlo  simulation  for 
generating  variances  for  K  and  td  one  can  perform  a  tradeoff 
analysis,  pick  a  reasonable  effort  (or  cost)  time  combina¬ 
tion  and  complete  the  sensitivity  analysis.  The  value  of 
simulating  several  thousand  Honte  Carlo  runs  is  that  it 
produces  a  measure  of  the  variation  in  effort  and  develop¬ 
ment  time,  or  the  risk  pro?  ile.  Knowing  the  sensitivities, 
the  Air  Porce  PH  can  use  it  effectively  in  planning  and 
contracting  so  that  the  risk  level  is  always  within  accep¬ 
table  range.  Examples  of  this  procedure  are  given  in  the 
COHPSAC  77  tutorial  (Putnam  and  Wolverton,  1977) . 


gift  BUS 

Three  options  are  available  to  the  user:  calibrate, 

editor,  estimate.  The  option  chosen  for  this  illustration 
was  "estimate.**  A  file  is  built  froa  the  previous  input 
data,  and  an  on-line  coanent  shows  that  the  input  data  check 
was  acceptable.  The  structure  of  the  on-line  output  is 
shown  below: 

a.  Suaaary  of  input  paraaeters:  table  of  all  inputs. 

Annotated  content  shows  Ck,  the  technology  constant, 
was  separately  coaputed  to  be  754. 

b.  Siaulation:  system  cost  suaaary  is  given  as  follows: 


Mean 

Std  Dev 

Systea  Size  (STMTS) 

22100.0 

1333.0 

Mini aum  Develop aent  tine 
(Months) 

34.8 

1.2 

Developaent  Effort  (Hanaonths) 

891.0 

106.9 

Development  Cost  (x  $1000) 

-  Oninflated  dollars 

4461.0 

711.0 

-  Inflated  dollars 

4887.0 

787.0 

c.  Sensitivity  profile  for  minimum  time  solution 
(i.e. ,  expected  values  of  time,  effort,  and  cost  for 
the  whole  size  profile): 


Source 

St  ateaents 

Months 

Man- 

Months 

Cost 

(x  $1000) 

-3  SD 

18100 

31.9 

525 

2627 

-1  SD 

2076  7 

33.9 

763 

3814 

Most  Likely 

22100 

34.8 

891 

4461 

♦  1  SD 

23433 

35.6 

1034 

5172 

♦  3  SD 

26100 

37.3 

1331 

6657 

Where  SD  »  Standard  Deviation 


A  cross-check  with  data  froa  other  systems  of  the 
saae  size  for  the  aost  likely  astiaates  is  given.  As 
ccapared  with  the  BA  DC  data  base  (which  is  a  Mixture 
of  software  projects),  the  reaarks  show  less  than 
noraal  productivity  for  avionics  OFP  software.  This 
is  to  be  expected. 

An  on-line  inforaation  note  gives  the  user  14  options 
for  the  reaaining  output;  several  of  these  will  be 
given  to  show  the  aanageaent  paraaeters  available. 
Linear  prograa:  this  function  uses  the  technique  of 

linear  prograaaing  to  deteraine  the  ainiaua  effort 
(and  cost)  or  the  ainiaua  tiae  in  which  a  systea  can 
be  built.  The  results  are  based  on  the  actual 
manpower,  cost,  and  schedule  constraints  of  the  user, 
coabined  with  the  systea  constraints  provided  earlier. 

1.  Enter  the  aaxiaua  development  cost  in  dollars. 
4500000 

2.  Enter  aaxiaua  development  tiae  in  months.  36 

3.  Enter  the  ainiaua  and  aaxiaua  number  of  people 
allowed  on  board  at  peak  manloading  tiae.  15,  40 

Cost 

Time  Effort  (x  J1000) 

Minimum  Cost  36.0  Months  778  MM  3892 

Miniaua  Time  34.8  Months  889  MM  4446 


A  tradeoff  analysis  within  these  limits  is  shown 
below. 


v-  / 


Time 


Ha  Months 


Cost  {x  $1000) 


34.8 

88  9 

4446 

35.0 

86  9 

4345 

35.2 

84  9 

4247 

35.4 

83  0 

4152 

35.6 

81  2 

4059 

35.8 

79  4 

3970 

36.0 

77  8 

3892 

h.  Front  end  estimate:  recall  that  the  SLIN  model 

assumes  that  the  estimated  time  length  is  from  logic 
design.  There fore,  a  separate  front  end  estimate  is 
required,  as  follows: 

Time  (months)  Effort  (HH) 

<L)  (B)  (H)  (L)  (E)  (&) 

Feasibility  7.8  8.7  9.6  9  35  61 

Study 

Functional  10.4  11.6  12.8  25  50  75 

Design 

Note:  L  *  Low,  E  *  Expected,  H  *  High 

i.  Hanloading:  The  table  shows  the  mean  projected  effort 
and  associated  standard  deviations  required  for  devel¬ 
opment.  The  input  parameters  are 
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V 


People/ 
Tiae  aonth 

Std 

Dev 

Cuaulative 

Hanaonths 

Cuaulative 
Std  Dev 

Jan 

74 

2 

0 

2 

0 

Feb 

74 

5 

1 

7 

1 

Bar 

4 

74 

t 

9 

« 

1 

• 

16 

• 

2 

• 

< 

4 

Oct 

» 

i 

76 

• 

• 

17 

• 

• 

2 

• 

• 

877 

• 

• 

105 

NOV 

76 

15 

2 

893 

107 

Dec 

76 

7 

1 

90  0 

108 

(This 

distribution 

of 

36  rows  1 

s  essentially 

Hayleigh  distribution  over  the  calendar  period  of 
performance,  with  integer  values  for  all  entries.).... 
o.  other  priaary  outputs  froa  the  Slia  cost  aodel 
include: 

1.  Code  production:  calendar  tine  versus  cuaulative 
source  stateaents 

2.  Coaputer  usage:  calendar  tine  versus  CPU  hours 

3.  Docuaentation:  expected  number  of  pages  of  docu- 

aentation 

4.  Design- to-cost :  SUB  has  provided  its  best  esti- 

aate  of  the  ainiaua  time  and  corresponding  aaximua 
effort  (  and  cost)  to  develop  your  systea.  & 
greater  effort  would  result  in  a  very  risky  tine 
schedule.  However,  if  a  lower  effort  is  specified 
(within  reasonable  limits),  development  is  still 
feasible  as  long  as  more  time  is  allowed. 

Entered  desired  effort  in  manmonths.  805 


125 


New  Development  Tiee  (Honths)  35.7 

Hew  Development  Cost  (x  $1000)  $4025 


1.2 

488.0 


5.  The  original  file  is  updated  with  these  new  param¬ 
eters*  and  the  user  can  run  sanloading  and  cash 
flow  or  life  cycle  to  see  how  these  savings  can  be 
realized.  This  can  be  used  interatively  to  natch 
sose  projected  benefit  stream  and  get  the  project 
approved.  (Connect  time  was  about  37  minutes  to 
run  SLIH*  at  a  cost  of  about  $25) 

In  summary*  the  SLIH  model  is  a  descriptive*  macro- level 
cost  estimating  tool  applicable  to  0FP  software*  provided 
that  its  technology  constant  (Ck)  is  calibrated  from  valid 
historical  OFP  project  data:  number  of  delivered  lines  of 

executable  source  code;  number  of  sannonths  from  project 
start  to  software  acceptance;  and  number  of  calendar  months 
for  the  development.  This  step  and  its  consequences  must  be 
understood  by  the  user.  SLIH  composes  the  feasibility  study 
and  functional  design  as  a  separate  front-end  estimate  which 
must  be  added  to  the  initial  cost  estimate.  Labor  mix  and 
work  breakdown  structure  information  is  not  given. 
Resources  are  allocated  against  time  (spread  by  a  Rayleigh 
distribution),  but  not  against  function  (e.g.  *  analysis  and 
design*  code  and  debug*  and  test  and  integration)  .  Ml 
statistical  parameters  are  assumed  to  be  normally  distrib¬ 
uted  for  mathmematical  tractability.  This  assumption  may 
contribute  to  the  extreme  sensitivity  between  minimum  cost 
and  minimum  time  as  shown  in  item  f*  linear  program  example; 
i.e.*  a  3  percent  change  in  calendar  time  (from  36  to  34.8 
months)  corresponds  to  a  1  4  percent  change  in  cost  (S3892K 


to  S4446K)  .  All  aatheaatical  expressions  used  in  the  coapu- 
tational  procedure  are  continuous  functions;  therefore  the 
aodel  will  always  produce  a  calculated  estiaate.  As  with 
all  aodels,  this  estiaate  aust  be  tested  against  experience 
and  huaan  insight. 
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II 


I 


TABLE  X 
Project  A  Data 


Actual 

Hanaths 

Tiae 

Mths 

Predicted  LC 
flanath  s 

Predicted  Haintenance 
Hanaths 

4.9600 

1 

2.60  05 

5.4600 

2 

5.0970 

7.1380 

3 

7.3683 

9.1380 

4 

9.3453 

11.9180 

5 

10.95  44 

12.1380 

6 

12.1522 

13.1380 

7 

12.9205 

12.1380 

8 

13.2663 

11.9240 

9 

13.21  83 

15.2690 

10 

12.82  35 

13.2800 

11 

12.1413 

9.8460 

12 

11.2388 

8.3077 

13 

10.1846 

10.8460 

14 

9.04  46 

6.8460 

15 

7.8778 

5.8460 

16 

6.7342 

5.8460 

17 

5.65  28 

3.0000 

18 

4.66  16 

1. 19124 

3.2800 

19 

3.77  80 

2.22748 

2.8400 

20 

3.01 01 

2.98686 

4.0000 

21 

2.35  83 

3.40398 

3.0000 

22 

1.8174 

3.47740 

2.0000 

23 

1.3778 

3.26075 

2.0000 

24 

1.0278 

2.84229 

2.0000 

25 

0.7545 

2.32054 

2-0000 

26 

0.54  51 

1.78318 

2.0000 

27 

0.3877 

1.29398 

2.0000 

28 

0.27  15 

0.88884 

1.5000 

29 

0.1871 

0.57894 

Actual  Tiae 
Hanaths  Mths 


Predicted  LC  Predicted  Haintenance 
Hanaths  Hanaths 


5^9200 

1 

3.86  88 

5.9200 

2 

7.41 28 

7.8600 

3 

10.35  23 

13.4200 

4 

12.43  88 

15.80  00 

5 

13.72  64 

15.5800 

6 

14.0751 

14.3400 

7 

13.6363 

12.5768 

13.1800 

8 

12.0200 

9 

11.09  66 

5.0000 

10  - 

9.3971 

4.3333 

2.7500 

11 

7.6564 

1.76084 

12 

6.01 21 

3.32648 

4.5556 

13 

4.5561 

4.53730 

4.4722 

14 

3.3355 

5.29599 

5.4167 

15 

2.36  10 

5.57900 

5.5000 

16 

1.6169 

5.43158 

5.6111 

17 

1.07  19 

4.94937 

3.7778 

18 

0.6882 

4.25312 

3.8889 

19 

0.42  80 

3.46350 

2.7778 

20 

0.2580 

2.68174 

1.5833 

21 

0.1508 

1.97898 

oinominiooooooooooooooooineoo 


Actual  Tiae 
Hanaths  Mths 


Predicted  LC  Predicted  Maintenance 
Hanaths  Hanaths 


1 

2.3213 

2 

5.51 54 

3 

7.96  44 

4 

10.0687 

5 

11.75  33 

6 

12.9721 

7 

13.7095 

8 

13.97  89 

9 

13.8191 

10 

13.28  88 

11 

12.4601 

12 

11.41  16 

13 

10.2221 

14 

8.9650 

15 

7.7044 

16 

6.4920 

17 

5.3669 

0.64025 

18 

4.3546 

1.25743 

19 

3.46  92 

1.82983 

20 

2.71 46 

2.33840 

21 

2.0368 

2.76779 

22 

1.5764 

3.10709 

23 

1.1704 

3.35022 

24 

0.8543 

3.49602 

25 

0.61 31 

3.54788 

Actual  Tiae 
Banaths  flths 


Predicted  LC  Predicted  Balntenance 
Hanath s  Banaths 


6.0000 

1 

3.85  85 

9.5200 

2 

7.1746 

8.5769 

3 

9.5312 

9.6369 

a 

10.7213 

9.6369 

5 

10.77  02 

1.17 00 

6 

9.8940 

0.2260 

7 

8.41 76 

8 

6.6828 

9 

4.97  49 

0.66747 

k  ■  l  ;  ♦  i 

10 

3.48  44 

1.31143 

i  1  i  i  i  i 

11 

2.30  15 

1.90977 

;  1  i  M  I 

12 

1.43 16 

2.44297 

F  1  <  •  l  i 

13 

0.84  77 

2.89525 

F>  *  •  3? 

14 

0.4738 

3.25522 

15 

0.25  10 

3.51641 

c  l  V  V  V  V 

16 

0.1261 

3.67722 

17 

0.0601 

3.74074 

'•  1  *  *  •  * 

18 

0.0272 

3.71413 

19 

0.01  17 

3.60786 

:  l  V  V  V  V 

*  1  -  *  > > 

38 

ol8o 19 

3.43475 

3.20901 

2.0000 

22 

0.00  07 

2.94528 

mi. i 

23 

24 

8:888? 

2.65777 

2.35956 

2.5000 

25 

0.00  00 

2.06207 

1.5000 

26 

0.00  00 

1.77470 

IWmTmJ 

■Pti^Tw 

27 

28 

0.0000 

0.0000 

1.50475 

1.25734 

1.5000 

29 

0.00  00 

1.03565 

30 

0.00  00 

0.84109 

1.0000 

31 

0.0000 

0.67365 

|Wilm 

■MuiU  »■! 

32 

0.00  00 

0.53218 

33 

0.00  00 

0.41475 

2.0000 

34 

0.00  00 

0.31892 

TA  BLE  XIV 


Coabined  Project  A-D  Data  Noraalized  to  td*1 


Actual 

Hanaths 


6.0088 
6.000  0 
5.4600 
5.9200 
7.500  0 

7.1380 
7.0000 
9.5200 

9. 1380 

um 

11.9180 
8.576  9 
12.5000 

12.  138  0 
7.8600 

12.5000 

9.6369 

13.  1380 
13.0000 
13.4200 
12.1380 

9.636  9 
14.0000 
11.9240 
11.1700 
15.269  0 
14.0000 
15.8000 
13.2800 
14.0000 
10.2260 

9.8460 
15.5800 
13.0000 

8.3077 
1 1.0000 
5.2800 
10.8460 
14.3400 
1  1.0000 

6.8460 
1.6800 
8.0000 

5.8460 
13.1800 

8.0000 

1:846  0 

il;8288 


Tiae  Predicted  LC 
Mths  Hanaths 


0.100  2.3128 

0.111  2.5637 

0.167  3.8213 

0.200  4.5433 

0.200  4.5433 

0.222  5.0151 

0.300  6.6140 

0.333  7.2503 

0.334  7.2692 

0.400  8.4568 

0.400  8.4568 

0.444  9.1807 

0.500  10.0167 
0.501  10.0307 
0.555  10.7390 
0.600  1  1.2541 
0.600  1  1.2541 
0.666  11.8826 
0.668  11.8993 
0.700  12.1468 
0.777  12.5957 
0.800  12.6900 

8:!Si  \hm 

.888  12.8875 
.900  1  2.8950 
1.000  12.7876 
1.000  12.7876 
1.000  12.7876 
1.000  12.7876 
1.100  12.4049 
1.  111  12.3478 
1.167  12.0167 
1.200  11.7921 
1.200  11.7921 
1.222  1  1.6313 
1.300  10.9993 
1.3  3  3  1  0.7  06  9 
1.334  10.6979 
1.400  10.0777 
1.400  10.0777 
1.444  9.6444 

1.500  9.0770 

1.501  9.0667 

1.535  8.7165 

1.600  8.0424 

1.600  8.0424 

1.666  7.3605 

1.668  7.3399 

1.700  7.0134 

1.777  6.2456 

1.800  6.0224 


8 


Predicted  Maintenance 
Hanaths 
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Table  XIV  continued 


Actual 

Tiae 

Predicted  LC 

Predicted  aaintenance 

Hanaths 

aths 

Manath s 

Sanaths 

3 
3 
3 

3.2800 


2.0000 


000 
167 
200 
334 
501 
668 
835 
000 
167 
334 
5.501 
5.668 


6.0224 
5.6  893 
5.2016 
5.0941 
4.2458 
4.2458 
4.2458 
4.2458 
3.4880 
3.4104 
3.0332 
2.8249 
2.8249 
2.6917 
2.2559 
2.0882 
2.0832 
1.7768 
1.7768 
1.5926 
1.3803 
1.3768 
1.2595 
1.0579 
1.0579 
0.8810 
0.8761 
0.7999 
0.6392 
0.5969 
0.5969 
0.5370 
0.4395 
0.3194 
0.3194 
0.1820 
0.1622 
0.1001 
0.0782 
0.0531 
0-0358 
0.0272 
0.0156 
0.0134 
Q-0065 
0.0065 
0.0030 
0.0025 
5.0013 
0.0006 
0.0002 
0.0001 
0.0000 
0.0000 
0.0000 
0.0000 
0.0000 


0.00528 

0.18457 

0.46312 

0.52590 

1.04203 

1.04203 

1.04203 

1.04203 

1.53892 

1.59202 

1.85663 

2.00771 

2.00771 

2.10625 

2.44037 

2.57399 

2.57797 

2.82995 

2.82995 

2.98621 

3.17078 

3.17393 

3.27772 

3.45858 

3.45858 

3.61804 

l.iiol! 

3.83018 
3.86530 
3.86530 
3.91294 
3.98301 
4.04514 
4.04514 
4.03290 
4.01462 
3.89258 
3.80710 
3.64877 
3.46657 
3.32901 
3.04092 
2.96117 
2.57596 
2.57596 
2.18624 
2.11088 
1.81450 
1. 47364 
1.17173 
0.91255 
0.69870 
0.52270 

0.19449 


HMTHS  UYES 


DATE 


HHES  HHTHS  HYRS 


0.797 
0.907 
1.039 
1.083 
1.  161 
1.249 
1.324 
1.362 
1.397 
1.394 

1.4  26 
1.260 
1.546 
1.490 
1.419 
1.539 
1.344 
1-177 
0.889 
0.567 
0.4  72 
0.349 
0.253 

3.4  32 
0.597 
0.542 
0.376 
0.4  44 
0.349 
3.368 
0.294 
3.376 
0.4  72 
3.4  95 
0.965 
3.714 
0.565 
3.569 
3-390 
3.4  03 
3.4  84 
3.484 


0.067 
0.07  4 
0.08  8 
0.089 
0.098 
0.106 
0.109 
0.115 
0.11  5 
0.118 
0.12  1 
0.100 
0.13  1 
0.122 
0.120 
0.126 
0.114 
0.100 
0.07  3 
0.048 
0.039 
0.030 
0.02  1 
0.033 
0.05  1 
0.044 
0.032 
0.03  6 
0.029 
0.03  1 
0.024 
0.032 
0.039 
0.042 
0.082 

Mil 

0.047 
0.03  3 
0.033 
0.04  1 
0.04  1 


9/78 

10/78 

11/78 

\2,W 

2/79 

3/79 

4/79 

5/79 

6/79 

7/79 

8/79 

9/79 

10/79 

11/79 

12/79 

1/80 

2/80 

3/80 

4/80 

5/80 

6/80 

7/80 

8/80 

9/80 

10/80 

11/80 

12/80 

1/81 

2/81 

3/81 

4/81 

5/81 

6/81 

7/81 

8/81 

9/81 

10/81 

11/C 

12/8 

1/82 


450 

0.625 

0.051 

450 

0.605 

0.051 

400 

0.556 

0.046 

410 

0.551 

0.047 

510 

0.685 

0.058 

420 

0.625 

0.048 

370 

0.497 

0.042 

410 

0.569 

0.047 

390 

0.524 

0.044 

440 

0.611 

0.050 

670 

0.901 

0.076 

520 

0.699 

0.059 

580 

0.806 

0.066 

440 

0.599 

0.050 

294 

0.4  08 

0.034 

275 

0.370 

0.031 

410 

0.551 

0.047 

367 

0.527 

0.042 

541 

0.727 

0.062 

482 

0.669 

0.055 

299 

0.402 

0.034 

449 

0.624 

0.051 

418 

0.562 

0.048 

216 

0.290 

0.025 

214 

0.297 

0.024 

230 

0.309 

0.026 

361 

0.501 

0.041 

377 

0.507 

0.043 

487 

0.655 

0.055 

628 

0.935 

0.072 

500 

0.672 

0.057 

537 

0.746 

0.061 

386 

0.519 

0.044 

321 

0.446 

0.037 

492 

0.661 

0.056 

656 

0.882 

0.075 

73 

0.  101 

0.008 

570 

0.766 

0.065 

416 

0.578 

0.047 

352 

0.473 

0.040 

8  30 

1.  116 

0.095 

TABLE  XVI  Project  A  Curves 


VA»U»IE  2  TIMET  VERSUS  VARIABLE  1  HANM1U  SYi4B0L*A 

Vi’lLltF  2  TIMET  VERSUS  VARIABLE  i  l*k  AMT  IT  SYMBOL** 

VARUBIF  2  TIMET  VERSUS  YAPIAULE  A  PPMAIN  SYMBOL** 


TABLE  XVIII  Project  C  Curve* 
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